IETF Logo Mail Archive

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

Martin Langer <mart.langer@ostfalia.de> Wed, 27 June 2018 12:17 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 8428012F1AB for <ntp@ietfa.amsl.com>; Wed, 27 Jun 2018 05:17:48 -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 A2dldP961uuE for <ntp@ietfa.amsl.com>; Wed, 27 Jun 2018 05:17:46 -0700 (PDT)
Received: from mailgate1.sonia.de (mailgate1.sonia.de [141.41.1.242]) (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 6B91D127598 for <ntp@ietf.org>; Wed, 27 Jun 2018 05:17:46 -0700 (PDT)
Received: from mailgate1.sonia.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0796D15848; Wed, 27 Jun 2018 14:17:45 +0200 (CEST)
Received: from mail.sonia.de (mail.sonia.de [141.41.8.70]) by mailgate1.sonia.de (Postfix) with ESMTP id C75BA15842; Wed, 27 Jun 2018 14:17:44 +0200 (CEST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_sSBctKUqb2+60ChKzCn64w)"
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 <0PAZ00G4HE5K5Y00@mail.sonia.de>; Wed, 27 Jun 2018 14:17:44 +0200 (CEST)
Sender: mart.langer@ostfalia.de
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: ntp@ietf.org
References: <81cc0512-5971-d36a-edc0-b5eae8f03023@ostfalia.de> <5de4efab-cee1-2402-186f-9f2bda3396d0@ostfalia.de> <20180627111217.GS22354@localhost>
From: Martin Langer <mart.langer@ostfalia.de>
Message-id: <01aad5dc-59ba-c8fd-ff97-0b9cbab88bd2@ostfalia.de>
Date: Wed, 27 Jun 2018 14:17:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
In-reply-to: <20180627111217.GS22354@localhost>
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:to:cc:references:from:message-id:date:in-reply-to; s=20140129; bh=AXsOJJTXysPyMz4sAWynu0IK/I8qzKgweI1el/rYvTs=; b=pW/FFt/OPQ2z92jmQQuYd+Nv2tSF9jNtdc60D776tGVYU5bE+/DzGfUYcrPr5bmWfEvvQCDu5ldGerhzgQ+tl5SN+IQIGiWy8eRdmt4uaJoHwgcCWMjH/3OYleEkJz3/G8UJCwjzKk3UYqqqEY3ZAjn+0suGpVVCo2+Kyy2+a7g=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/v88vJluVgziyH2TaTovMunBFsKA>
Subject: Re: [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 12:17:49 -0000

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 ;)



Am 27.06.2018 um 13:12 schrieb Miroslav Lichvar:
> 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.
>
>> 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
> That's a good point. We should also not forget that clients may use
> extension fields for other things than NTS.
>

-- 
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

v2.23.0 | Report a Bug | By Email