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

[Martin Langer <[e-mail]>]

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,[e-mail]  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. : [phone]
Fax  : [phone]
Mail :[e-mail]
Web  :http://www.ostfalia.de/cms/de/e