Re: [TLS] Resolution on gmt_time

Eric Rescorla <ekr@rtfm.com> Fri, 18 July 2014 22:57 UTC

Return-Path: <ekr@rtfm.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 AF8611A02A2 for <tls@ietfa.amsl.com>; Fri, 18 Jul 2014 15:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 uQ8rfPOhjalg for <tls@ietfa.amsl.com>; Fri, 18 Jul 2014 15:57:12 -0700 (PDT)
Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA8A1A02A3 for <tls@ietf.org>; Fri, 18 Jul 2014 15:57:11 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id p10so5215547wes.2 for <tls@ietf.org>; Fri, 18 Jul 2014 15:57:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZhkMNzslIhAOWjp0+5+PPD9zpcOKM6eaN1d+Nzl4IsM=; b=iOhZAUDYk265Tx9SR5o+3Rtlr04vE9MJB8Dc6oQzXNlgQ1UHOsQH6fFSHb9z1gYiHr 1JCmLkSnuoU7629fcoDt146lzbuv31IvjHnci/aXu421OS1gWu4oxd9PPY3fRFh+wvum gls62GwwqGt9GACJtTnuxEEo7Jaqx2Ood7Mx6X58G2saA992OF8GVPoNsPROQsqeKr3X 8SU8EzcAiC6sT6wOrjj846bFQs0y8/lMMlryRCvbbztH42Bz9dRnA12SbbzI7o7LXMyh +SAsJDh18Jk7bPcRjFT7TiHqwfF7MeI7heLMtfBYGlAiz6i0KeKOJhG6cHbMLuauBo+c +ajw==
X-Gm-Message-State: ALoCoQkvUHXPPCS0DrN+BM0bTNmTxhyyhAwTBe16cOmMWcYLwhqKT3fj3nepc3zQ6ZpiKAbYN4OB
X-Received: by 10.180.78.100 with SMTP id a4mr22114528wix.36.1405724230366; Fri, 18 Jul 2014 15:57:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.128.12 with HTTP; Fri, 18 Jul 2014 15:56:30 -0700 (PDT)
X-Originating-IP: [2620:101:80fc:232:69e8:5ca6:d68c:fe87]
In-Reply-To: <FDFA7387-D6C7-4A6B-916F-C9CB8D142F49@cisco.com>
References: <338B3B88-CCE5-4D79-97DC-1EC7D84891AA@cisco.com> <CABcZeBP7hTxL59+0GmRH1PYGr8g3+=cdXE3dsHmmGHDnJcOz3A@mail.gmail.com> <FDFA7387-D6C7-4A6B-916F-C9CB8D142F49@cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 18 Jul 2014 15:56:30 -0700
Message-ID: <CABcZeBOqCkvBYHSM+=2_McfCNCvj=hwi+gwG62RfOyRm+BsxAA@mail.gmail.com>
To: Dan Wing <dwing@cisco.com>
Content-Type: multipart/alternative; boundary=f46d043890eb67781a04fe7fad38
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rltuMZ161p1cq89kw4T7fw5gvxc
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Resolution on gmt_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: Fri, 18 Jul 2014 22:57:13 -0000

I left this as an open issue per chair direction:

https://github.com/tlswg/tls13-spec/issues/64

I'll take this as an argument on one side of the issue. Let's discuss
in YYZ.

-Ekr





On Fri, Jul 18, 2014 at 3:51 PM, Dan Wing <dwing@cisco.com> wrote:

> It reads for TLS 1.3:
>   Server implementations MAY opt to include the time in their
>   Server.random values in order to accomodate clients which use
>   that field for time synchronization.
>
> How does the TLS server know if the client uses the field for
> synchronization?  This feels like an excuse for a lazy implementation to
> leave it in, and the text does not explain the risk. Yes, there is a risk
> -- peer-to-peer TLS or peer-to-peer DTLS (such as for WebRTC and
> DTLS-SRTP).  I would rather kill this entirely, and if someone needs
> synchronization they can run TLS 1.0-1.2, or use some other protocol like
> NTP.
>
> -d
>
>
> On Jul 16, 2014, at 8:09 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> See https://github.com/tlswg/tls13-spec/pull/65
>
> Expected merge date: Friday Jul 18
>
>
> On Sun, Jun 22, 2014 at 10:17 PM, Joseph Salowey (jsalowey) <
> jsalowey@cisco.com> wrote:
>
>> Thanks all. Based on the list discussion, the chairs believe there
>> is rough consensus on the following points:
>>
>> For TLS 1.3:
>> - Remove GMT time from the ClientHello entirely.
>> - Remove GMT time from the ServerHello at the MUST or SHOULD level.
>>
>> For TLS 1.2:
>> - Remove GMT time from the ClientHello entirely.
>> - Remove GMT time from the ServerHello at the SHOULD level.
>>
>> Next steps for TLS 1.3 are as follows:
>> The editor is directed to remove GMT time from both random values
>> and open an issue as to whether or not the ServerHello can have
>> a time value in it.
>>
>> Next steps for TLS 1.2 are as follows:
>> Absent any objections, the chairs intend to adopt draft-matthewson
>> as a WG draft. Anyone who objects to this, please say something by
>> Friday June 27.
>>
>> Joe
>> (For the chairs)
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>