Subject: [Ntp] TLS records vs NTS-KE

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 26 Jun 2018 13:08:22 +0200

I'm trying to understand the relation between TLS records and NTS-KE
records. I'm still new to TLS and it's not obvious to me from the
nts-for-ntp draft.

It seems the maximum length of a NTS-KE record is 4 + 65535 octets,
but TLS records can be only about 16K. Does that mean NTS-KE records
and NTS-KE requests/responses can span multiple TLS records? Is this
the reason why there is the End Of Message record?

I think it would make implementations simpler if we could assume the
NTS-KE request and response were just a single TLS record containing
all necessary NTS-KE records. Do we expect a new NTS Next Protocol to
be specified that would not work with such restrictions?

Also, would it be possible to specify an upper limit for the length of
the cookie? It has to fit in an NTP packet, so maybe something like
256 octets would be reasonable? 

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Tue, 26 Jun 2018 08:52:36 -0400

TLS records generally correspond to TCP packets. Application-level
protocols that run over TLS don't (or at least really shouldn't)
assign any semantics to record boundaries just like they don't assign
any semantics to TCP packet boundaries; the abstraction provided at
the application level is just a stream of bytes.

On Tue, Jun 26, 2018 at 7:08 AM, Miroslav Lichvar <[email-masked]> wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 26 Jun 2018 16:11:48 +0200

> the application level is just a stream of bytes.

Ok. Thanks. I thought the TLS record size was fully under the control
of the application and was independent from the MTU.

I think there should be some limits for the maximum length of the
request, response and cookie. We don't want to require servers to
accept infinitely long requests, right?

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Tue, 26 Jun 2018 17:54:25 +0200

Miroslav,

I suggest that you read the current working document of this draft. You 
will find it under; 
https://github.com/dfoxfranke/nts/blob/master/draft-ietf-ntp-using-nts-for-ntp.xml
It shall be submitted to the IETF website soon.

Dieter

"ntp" <[email-masked]> schrieb am 26.06.2018 16:11:48:

> Von: "Miroslav Lichvar" <[email-masked]>
> An: "Daniel Franke" <[email-masked]>
> Kopie: [email-masked]
> Datum: 26.06.2018 16:12
> Betreff: Re: [Ntp] TLS records vs NTS-KE
> Gesendet von: "ntp" <[email-masked]>
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 27 Jun 2018 10:03:01 +0200

> It shall be submitted to the IETF website soon.

I looked at the new text, but didn't find anything related to the
maximum length of the messages or cookies.

If I understand it correctly, both servers and clients are currently
required to ignore unknown records with the critical bit unset. This
enables interoperability with future implementations which may use a
currently unknown record, e.g. for a different NTS Next Algorithm.

However, there doesn't seem to be anything that would limit their
number in the message, except maybe the implementation-specific
timeout for receiving a complete request. If a (broken) client tries
to make a request with an infinite number of unknown non-critical
records, the server should be able to shutdown the connection before
wasting too much bandwidth. Similarly, a client should be able to stop
receiving an infinitely long response.

NTS-KE is a simple protocol to exchange tiny bits of data. It's not
supposed to be a general-purpose web server. My suggestion is to
specify a reasonable maximum length of the request, response and
cookie. This will allow implementors to determine an upper bound on
the amount of memory needed for NTS and also allow a simpler
implementation parsing whole messages at once instead of a stream of
individual records. Imagine an implementation on a microcontroller
with a few dozens of kilobytes of RAM.

It seems with current implementations we can expect requests to have
20 octets, cookies about 100-200 octets and responses about 800-2000
octets. The current 64K limit for a cookie is way too much.

To start with something more specific, I propose the following limits:

request: 1K
response: 16K
cookie: 256

Thoughts?

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 28 Jun 2018 14:24:15 +0200

> the application level is just a stream of bytes.

Another question related to the TLS application in NTS. The draft
says:

	Immediately following a successful handshake, the client SHALL
	send a single request (as Application Data encapsulated in the
	TLS-protected channel), then the server SHALL send a single
	response followed by a TLS "Close notify" alert and then
	discard the channel state.

I guess that means the client shouldn't bother responding with
close_notify. Is that correct? Would it make sense to explicitly say
that in the draft?

-- 
Miroslav Lichvar