Re: [Dtls-iot] Reference to mathewson-no-gmtunixtime
Carsten Bormann <cabo@tzi.org> Wed, 15 July 2015 11:46 UTC
Return-Path: <cabo@tzi.org>
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 414FC1A8994 for <dtls-iot@ietfa.amsl.com>; Wed, 15 Jul 2015 04:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
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 bAU0Ze26FXvI for <dtls-iot@ietfa.amsl.com>; Wed, 15 Jul 2015 04:46:31 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 5EEC71A8992 for <dtls-iot@ietf.org>; Wed, 15 Jul 2015 04:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t6FBkNBb021051; Wed, 15 Jul 2015 13:46:23 +0200 (CEST)
Received: from alma.local (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mWcPC4XxhzD2gB; Wed, 15 Jul 2015 13:46:23 +0200 (CEST)
Message-ID: <55A6480E.5030405@tzi.org>
Date: Wed, 15 Jul 2015 13:46:22 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.1 (Macintosh/20150514)
MIME-Version: 1.0
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
References: <55A6420E.7040703@gmx.net>
In-Reply-To: <55A6420E.7040703@gmx.net>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dtls-iot/X7Q3Q1N1cL5-TZvFNlfgZAx4OrA>
Cc: "dtls-iot@ietf.org" <dtls-iot@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [Dtls-iot] Reference to mathewson-no-gmtunixtime
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: Wed, 15 Jul 2015 11:46:33 -0000
Hannes Tschofenig wrote:
> a) Remove the reference to mathewson-no-gmtunixtime and point out that
> somewhere a secure time source needs to be made available.
>
> b) Copy the relevant text from mathewson-no-gmtunixtime into this
> document (with appropriate attribution). mathewson-no-gmtunixtime cites
> a different motivation for doing what he suggests, which I believe is
> less applicable to our scenario.
>
> c) Work with Mathewson on mathewson-no-gmtunixtime to get it finished.
> The profile document would be blocked till that time.
>
>
> If you ask me for a preference then I would probably go for (b). I am
> not sure it is, however, in the mandate of the working group to define
> TLS-specific functionality.
Hmm, profiling this specific field in a way that makes sense for a
constrained implementation is well in the purview of the WG.
Also, 5246 says:
gmt_unix_time
The current time and date in standard UNIX 32-bit format
(seconds since the midnight starting Jan 1, 1970, UTC, ignoring
leap seconds) according to the sender's internal clock. Clocks
are not required to be set correctly by the basic TLS protocol;
higher-level or application protocols may define additional
requirements. Note that, for historical reasons, the data
element is named using GMT, the predecessor of the current
worldwide time base, UTC.
"Clocks are not required..."
"higher-level or application protocols may define..."
The license to fix this in a profile is right there.
(b) is the right way to handle this. ✅
(On a technical level, it seems the intention was to have a source of
entropy that also has a good chance to be unique over time. No idea
whether this sentiment should be picked up here.)
Grüße, Carsten
- [Dtls-iot] Reference to mathewson-no-gmtunixtime Hannes Tschofenig
- Re: [Dtls-iot] Reference to mathewson-no-gmtunixt… Carsten Bormann
- Re: [Dtls-iot] Reference to mathewson-no-gmtunixt… Hannes Tschofenig