[Dtls-iot] Secure Time Summary

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 17 August 2015 10:20 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB2E1A9031 for <dtls-iot@ietfa.amsl.com>; Mon, 17 Aug 2015 03:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 1tXRWm6qkg7N for <dtls-iot@ietfa.amsl.com>; Mon, 17 Aug 2015 03:20:36 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85ABF1A9030 for <dtls-iot@ietf.org>; Mon, 17 Aug 2015 03:20:36 -0700 (PDT)
Received: from [192.168.131.138] ([80.92.114.40]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LosFD-1Yq0y10OHT-00gqMO for <dtls-iot@ietf.org>; Mon, 17 Aug 2015 12:20:34 +0200
Message-ID: <55D1B571.2040209@gmx.net>
Date: Mon, 17 Aug 2015 12:20:33 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: "dtls-iot@ietf.org" <dtls-iot@ietf.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Croke9bGMaDiP8vIFj82Kfpj9F6vh63Da"
X-Provags-ID: V03:K0:UGcv6YKLfUHrScpYlNbI8JGcNSRI7XhJhypxE31CrVszBKEOyAS 52ZWGKBT6ql9Iwla6E0j6xcaR2i9pllt9KI9cQznDvoFalt68AN51a53quB8ew6o/4vwhXJ dLJicQzOGDGmwlc567vUxAQcb6UKKOqUOTuPNFHYGO3ZxFAQjoM7+cWODasWMQIeQ7PFUU6 ZfhWA06kCyLrEhFVz/uCw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:YNYgGEGtyTk=:Sn91iTla3QlBLhOYcSGwth zVPuQBuAe3Lr9TohQvkzp1crvhWUMrxAWmNMQ2uIMoC93ud5ygluo88lScw3WzvyglGhm7iAv e2dItNE5Fs2VMNaZ0QXWv8URLbU/VgJgVW4Ie0Jm8ilKcaw3BwUxuhNDoKl3BOeip24JUyw07 icdVKi+yian9/t0p/UorJfUgsq7zJuwMuI4mobgbR2+nOiTtcTtetZOQKoOHZlpPhqm34DtCD GTZkbI5xQAAP79ichTHiPivbcDWL2hklx79GO0tAhjr9sbHpAtF+rcZexVtWUfQZ+rnrHqLA3 d7BSpY0aG5ns7GEqJdoXTYGqocekrL5XO2tjACUhTMx4OwSjj8p1brkMSCPYWHCDw3wURO1MB 2/IyAn2dR8eCx6XcRhNWHDfCBLuy2CrOFmd+AV13nzU45+QMQ117d4IWGmi41cf+GaRxf3R0R hdtzMsIMHcUTjqgmSI6SWUWsPx0nGnkerDyPQ/GpJlSzXvebpUqi46n5tglrdDrr6UlT+1yTA vEYev9G4OXKo4v8eG9ECBN1oEsd9GrW3q07IV6Vay58N5zl/1ILUXPJtzSXK6ik+boDIv77Rb MVWCHL0Gsm+S2CA4YZsOkeSuDPWA93WFTTV+JFzw4hkwyUBQDkrqc9/DG31cbTfJVg6vWZcL8 jVh3ChezfO2S+WHNp1tBOpul4r4VLi5eS65nZp0Fgt2ftMfKHc09WUYg6eZZ6WvtQLthm1iaj GIGFT6RZiWSjKNuX
Archived-At: <http://mailarchive.ietf.org/arch/msg/dtls-iot/k1yGOXlqDTEA-RkDseBZirDaQFE>
Subject: [Dtls-iot] Secure Time Summary
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2015 10:20:39 -0000

Hi all,

this topic lead to a longer discussion; references are here:
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00628.html
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00629.html
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00657.html

The conclusion seems to be that we do not want to incorporate a secure
network time protocol functionality into the TLS protocol but rather
offer it on a higher layer.

Thanks for your feedback.


I therefore suggest to change the following paragraph

FROM:

---------

   The ClientHello and the ServerHello messages contains the 'Random'
   structure, which has two components: gmt_unix_time and a sequence of
   28 random bytes. gmt_unix_time holds the current time and date in
   standard UNIX 32-bit format (seconds since the midnight starting Jan
   1, 1970, GMT).  [I-D.mathewson-no-gmtunixtime] argues that the entire
   ClientHello.Random value (including gmt_unix_time) should be a
   sequence of random bits because of device fingerprinting privacy
   concerns.  Since many IoT devices do not have access to an accurate
   clock, it is RECOMMENDED to follow the guidance outlined in
   [I-D.mathewson-no-gmtunixtime] regarding the content of the
   ClientHello.Random field.  However, for the ServerHello.Random
   structure it is RECOMMENDED to maintain the existing structure with
   gmt_unix_time followed by a sequence of 28 random bytes since the
   client can use the received time information to securely obtain time
   information.  For constrained servers it cannot be assumed that they
   maintain accurate time information; these devices MUST include time
   information in the Server.Random structure when they actually obtain
   accurate time information that can be utilized by clients.  Clients
   MUST only use time information obtained from servers they trust and
   the use of this approach has to be agreed out-of-band.

---------

TO:

---------

   The ClientHello and the ServerHello messages contains the 'Random'
   structure, which has two components: gmt_unix_time and a sequence of
   28 random bytes. gmt_unix_time holds the current time and date in
   standard UNIX 32-bit format (seconds since the midnight starting Jan
   1, 1970, GMT). Since many IoT devices do not have access to an
   accurate  clock, it is RECOMMENDED to place a sequence of random
   bytes in the two components of the 'Random' structure when creating
   a ClientHello or ServerHello message and not to assume a structure
   when receiving these payloads.

   When TLS is used with certificate-based authentication the
   availability of time information is needed to check the validity of
   a certificate. Higher-layer protocols may provide secure time
   information. The gmt_unix_time component of the ServerHello is not
   used for this purpose.

---------

Ciao
Hannes

PS: This text is documented in issue#31 (and issue #32 was merged with
issue #31).