Re: [TLS] Server time

Dave Garrett <davemgarrett@gmail.com> Sat, 04 April 2015 21:09 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D4D1A00DC for <tls@ietfa.amsl.com>; Sat, 4 Apr 2015 14:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 LK7DMPIeIlxM for <tls@ietfa.amsl.com>; Sat, 4 Apr 2015 14:09:30 -0700 (PDT)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4A51A0030 for <tls@ietf.org>; Sat, 4 Apr 2015 14:09:29 -0700 (PDT)
Received: by qgdy78 with SMTP id y78so54739qgd.0 for <tls@ietf.org>; Sat, 04 Apr 2015 14:09:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=mBwuEU2VlSk0ecorWxVb9xw14LIK2rBhn4wcuvsZNtE=; b=yEUHZnIa+634dI2Ryv1sl0WrZVXptRqaJN1Pig0hbrWuKSTt8lVoREB/+JrGukM9T7 ZoeIMnC6njjc28BqkLAPdQHdwgtWKC3TpAQ93jYhtNYy7fqWjgIK2sM8Pamc7arcSETF lioI62awqJ/kFC9b7M/u7fyzEtnTXPkbMC/4RijfXNIg/pqAlL70+KOabMQPuykhZbbH aRd6fbjPj081eAS5a6aIU67svMOxFp5y2QJo7cLRaosWDABd8T7ouOfHuguR7hxXoLM0 W9VVoqhJ1pixXLt9PAZM+f5e46KUN++iWBQltZshz5e7tJoAZhkomAdQh6OvSISW9g1C R7IA==
X-Received: by 10.140.32.34 with SMTP id g31mr9145434qgg.74.1428181769047; Sat, 04 Apr 2015 14:09:29 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id s7sm175217qgd.4.2015.04.04.14.09.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 04 Apr 2015 14:09:28 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: Erik Nygren <erik@nygren.org>
Date: Sat, 04 Apr 2015 17:09:27 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <201504041352.12431.davemgarrett@gmail.com> <CAKC-DJj0rKNVXc1XJ4W2yiGY2bXYsXtAfubGEmO8JsoBu2kfvA@mail.gmail.com>
In-Reply-To: <CAKC-DJj0rKNVXc1XJ4W2yiGY2bXYsXtAfubGEmO8JsoBu2kfvA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201504041709.27640.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/M1yKdchFLY2fXM0X4FoTexfZLxI>
Cc: tls@ietf.org
Subject: Re: [TLS] Server time
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Apr 2015 21:09:31 -0000

On Saturday, April 04, 2015 03:53:31 pm Erik Nygren wrote:
> If we do, can we please make the extension y2038 safe?  With 17 years to go
> when this launches, that will be the same age as tls 1.0 and older than
> sslv3.

Yeah, I suggested uint32, which will last the century. Not worth the extra 4 bytes to go 64-bit, IMO. Nobody should be still using this at the beginning of the 22nd century. (if someone does, and is looking back in time in the archives: upgrade your crap)

The previous not-random-but-in-random time was uint32 as well, so that was fine so long as clients actually handled it properly. A warning could be added about signage saying not to ever treat it as signed and that after reading as uint32, it should probably be handled as int64 or whatever type the implementation uses for time values.


Dave