Subject: [Ntp] Fwd: Re: Antwort: Re: TLS records vs NTS-KE

From: Martin Langer <[email-masked]>
Date: Wed, 27 Jun 2018 12:38:19 +0200

Hello Miroslav,

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.

correct.

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.

I agree.

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:

ok, umm....
I think a size limitation is a good idea.

request: 1K

But what can we do if we need requests larger than 1K (maybe in the 
future)?
For example: A new record type needs parameters/key 
material/certificates and the size of this records is over 1K.
...but ok. Actually it is not a problem, I guess.

response: 16K

I think the 16k respons size is fine.

cookie: 256

The definition of the cookie size is a bit ...tricky. ...and do you mean 
the cookie itself or the whole record?

Calculation of a BIG cookie (according our nts draft) with:
- AEAD_AES_SIV_CMAC_512 algorithm
- 32 byte nonce
- 4 byte key identifier (defined by the server implementation)
- size of S2C/C2S dependents on the used AEAD algorithm

CookiePlain = AEAD_AlgoID || S2C || C2S
CookiePlain = 2 bytes + 64 bytes + 64 bytes
CookiePlain = 130 bytes

CookieCrypt = output of the AEAD operation (over CookiePlain)
CookieCrypt = {sizeOf(CookieCrypt) || authentication tag (always 16 bytes)}
CookieCrypt = {130 bytes + 16 bytes}
CookieCrypt = 146 bytes

CookieFinal =  KeyID || nonce || CookieCrypt
CookieFinal = 4 bytes + 32 bytes + 146 bytes
CookieFinal = 182 bytes

....so 256 byte should be enough, even if the nonce is larger (e.g. 64 
bytes).

But the NTP connection can be interessting:
- max. space for NTS extension fields:  1500 bytes MTU (Ethernet) - 20 
bytes IPv4 header - 8 bytes UDP header - 48 bytes NTPv4 header = 1424 bytes
- UniqueID_ExtField and AuthAndEncExt_ExtField need around 80 bytes --> 
so we have 1344 bytes for cookies EFs
- current guideline: max. 8 cookies or placeholder  ---> 1344/8 = 168 
bytes (without IP fragmentation)
...but I think this is not a problem. With a limit of 255 bytes we can 
transmit 5 cookies/placeholder without  IP fragmentaion

best regards,
Martin

Am 27.06.2018 um 10:03 schrieb Miroslav Lichvar:
> On Tue, Jun 26, 2018 at 05:54:25PM +0200,[email-masked]  wrote:
>> 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.
> 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?
>

-- 
Martin Langer, M.Eng.
Labor Datentechnik
Labor Design Digitaler Systeme

Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel -
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Tel. : +49 5331 939 43370
Fax  : +49 5331 939 43372
Mail :[email-masked]
Web  :http://www.ostfalia.de/cms/de/e

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 27 Jun 2018 13:12:17 +0200

On Wed, Jun 27, 2018 at 12:38:19PM +0200, Martin Langer wrote:
> But what can we do if we need requests larger than 1K (maybe in the future)?
> For example: A new record type needs parameters/key material/certificates
> and the size of this records is over 1K.
> ....but ok. Actually it is not a problem, I guess.

Do you think there might be a case where we would need to exchange
keys or certificates as application data? I'd expect that to be
handled by TLS itself.

If it does turn out later that 1K is too small for a request, in the
worst case I think we can always define "ntske/2" as a new ALPN name
for the same protocol with larger limits.

> cookie: 256
> 
> The definition of the cookie size is a bit ...tricky. ...and do you mean the
> cookie itself or the whole record?

Just the cookie, i.e. the data the client has to save in order to send
a valid NTP+NTS packet after NTS-KE is finished.

> - max. space for NTS extension fields:  1500 bytes MTU (Ethernet) - 20 bytes
> IPv4 header - 8 bytes UDP header - 48 bytes NTPv4 header = 1424 bytes
> - UniqueID_ExtField and AuthAndEncExt_ExtField need around 80 bytes --> so
> we have 1344 bytes for cookies EFs
> - current guideline: max. 8 cookies or placeholder  ---> 1344/8 = 168 bytes
> (without IP fragmentation)
> ....but I think this is not a problem. With a limit of 255 bytes we can

That's a good point. We should also not forget that clients may use
extension fields for other things than NTS.

-- 
Miroslav Lichvar

---

From: Martin Langer <[email-masked]>
Date: Wed, 27 Jun 2018 14:17:44 +0200

Do you think there might be a case where we would need to exchange keys 
or certificates as application data? I'd expect that to be handled by 
TLS itself. If it does turn out later that 1K is too small for a 
request, in the worst case I think we can always define "ntske/2" as a 
new ALPN name for the same protocol with larger limits.

um... indeed :)
Yeah... I think you're right ;)

Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel -
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Tel. : +49 5331 939 43370
Fax  : +49 5331 939 43372
Mail : [email-masked]
Web  : http://www.ostfalia.de/cms/de/e