[Ntp] Fwd: Re: Antwort: Re: TLS records vs NTS-KE
Martin Langer <mart.langer@ostfalia.de> Wed, 27 June 2018 10:38 UTC
Return-Path: <mart.langer@ostfalia.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30849130F70 for <ntp@ietfa.amsl.com>; Wed, 27 Jun 2018 03:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonia.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A6yXd4wVS8V for <ntp@ietfa.amsl.com>; Wed, 27 Jun 2018 03:38:21 -0700 (PDT)
Received: from mailgate2.sonia.de (mailgate2.sonia.de [141.41.1.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E5C130EC0 for <ntp@ietf.org>; Wed, 27 Jun 2018 03:38:21 -0700 (PDT)
Received: from mailgate2.sonia.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BBA0111466 for <ntp@ietf.org>; Wed, 27 Jun 2018 12:38:19 +0200 (CEST)
Received: from mail.sonia.de (mail.sonia.de [141.41.8.70]) by mailgate2.sonia.de (Postfix) with ESMTP id A3B8811460 for <ntp@ietf.org>; Wed, 27 Jun 2018 12:38:19 +0200 (CEST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_1ywBznIzY6E+QItxifKJ/g)"
Received: from [141.41.39.246] (unknown [141.41.39.246]) by mail.sonia.de (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Jan 25 2016)) with ESMTPSA id <0PAZ009VI9JVIY10@mail.sonia.de> for ntp@ietf.org; Wed, 27 Jun 2018 12:38:19 +0200 (CEST)
Sender: mart.langer@ostfalia.de
References: <81cc0512-5971-d36a-edc0-b5eae8f03023@ostfalia.de>
To: ntp@ietf.org
From: Martin Langer <mart.langer@ostfalia.de>
X-Forwarded-Message-Id: <81cc0512-5971-d36a-edc0-b5eae8f03023@ostfalia.de>
Message-id: <5de4efab-cee1-2402-186f-9f2bda3396d0@ostfalia.de>
Date: Wed, 27 Jun 2018 12:38:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
In-reply-to: <81cc0512-5971-d36a-edc0-b5eae8f03023@ostfalia.de>
Content-language: de-DE
X-Antivirus: Avast (VPS 180627-0, 27.06.2018), Outbound message
X-Antivirus-Status: Clean
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sonia.de; h=mime-version:content-type:sender:subject:references:to:from:message-id:date:in-reply-to; s=20140129; bh=omhMRE2RPySXhqin87posOSXPNTdPhsJ7Q0k9Kfblig=; b=C0Rt77Pwjz2j7Je2hv5CwbKAYc3CwsvEOBh/oSyzQ0gYM0L0qnlWS/txyvKSonTYVoIjHZUOxO1r/L+RbnbB90riqkJZe86KrB92de7SBtQNue7Ua7EI/8rO6RKIMubX3clksp5W1eGHZ9YIfry5iVsM1b/ySfKOplRpe5tdbDs=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/By8kLwbGisX-wVQD1HCzPOBlChk>
Subject: [Ntp] Fwd: Re: Antwort: Re: TLS records vs NTS-KE
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2018 10:38:25 -0000
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,dieter.sibold@ptb.de 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 :mart.langer@ostfalia.de Web :http://www.ostfalia.de/cms/de/e
- Re: [Ntp] Fwd: Re: Antwort: Re: TLS records vs NT… Martin Langer
- Re: [Ntp] Fwd: Re: Antwort: Re: TLS records vs NT… Miroslav Lichvar
- [Ntp] Fwd: Re: Antwort: Re: TLS records vs NTS-KE Martin Langer
- Re: [Ntp] Antwort: Re: TLS records vs NTS-KE Miroslav Lichvar
- Re: [Ntp] TLS records vs NTS-KE Miroslav Lichvar
- Re: [Ntp] TLS records vs NTS-KE Daniel Franke
- [Ntp] TLS records vs NTS-KE Miroslav Lichvar
- [Ntp] Antwort: Re: TLS records vs NTS-KE dieter.sibold
- Re: [Ntp] TLS records vs NTS-KE Miroslav Lichvar