[TLS] Removing the "hint" from the Session Ticket Lifetime hint
Nick Sullivan <nick@cloudflare.com> Tue, 23 February 2016 17:42 UTC
Return-Path: <nick@cloudflare.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 711FA1ACE9A for <tls@ietfa.amsl.com>; Tue, 23 Feb 2016 09:42:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 YkZ6iIfQjytl for <tls@ietfa.amsl.com>; Tue, 23 Feb 2016 09:42:37 -0800 (PST)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 91AE81ACD3A for <tls@ietf.org>; Tue, 23 Feb 2016 09:42:37 -0800 (PST)
Received: by mail-yw0-x231.google.com with SMTP id h129so152679122ywb.1 for <tls@ietf.org>; Tue, 23 Feb 2016 09:42:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=iNMSTq98xpcCPLEWXOdEgJherGYF1m23mo0qF8npRM0=; b=qOetAIvid+feq/adKI/CiJkvOWYDWKzO94u55aWeTSYpHt/XiKE+Ih/FdKCYVf8A6N 2qxbrlgjbmQA4/WUzmtX1MM8F3JQFKwPaU0g3QocxwUNwSHYe5xKNytHM53blV65I27V jyNcafj/jHxO1PCitZZFtL4DJdJm7klHCI+AY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=iNMSTq98xpcCPLEWXOdEgJherGYF1m23mo0qF8npRM0=; b=SknZ8YHGkPc3k1bj1+rIukNm/dli7K8mY0f73sbe5E6IuzBPiSUUlb3OUNu/5LnZqy Bd9GaAiws8MFpEkCM3AdmldWixtzyEMY5Sjn5VbZYnSOySxWmUKV5fGlUIgv4qnQyfI1 jHFkFoh9W+EyBEQTFjuRM2awXGcDCOTaaTs0PC9ESHaTwy6K6FHMFFCK6fnfvc+evRoF wtPLWA1TLD99/SHLanxLgEmJ1dWl7/GK8Q4wMMX/CI9Amaixdfr8ZcVXxCm2og7Rk88A Gd1N9vLbVqk6rMt9zdous14ZaaUiXUM6937RGFFOEB9sENg9fZLjCVW6ITh6ptcBYXSu XbDQ==
X-Gm-Message-State: AG10YOQNzLbY8fcfxCFGQ7vUzQDeq1xkeuyKK8jfhvXFs+1gDdCXIYD1QstDlbcsKKl3u+V6nuM6YlbBlkWMNFKl
X-Received: by 10.13.243.67 with SMTP id c64mr17889695ywf.306.1456249356828; Tue, 23 Feb 2016 09:42:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.86.67 with HTTP; Tue, 23 Feb 2016 09:42:17 -0800 (PST)
From: Nick Sullivan <nick@cloudflare.com>
Date: Tue, 23 Feb 2016 09:42:17 -0800
Message-ID: <CAFDDyk_dFOwv=GiQY7FdPqVcBR2ynN1fg0FzU8LeiYVDFPgArQ@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0355749e75da052c737940"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/iW-jWAXFlyu04XIvTa0-OzhEdU8>
Subject: [TLS] Removing the "hint" from the Session Ticket Lifetime hint
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 23 Feb 2016 17:42:39 -0000
Draft 11 currently supports both ServerConfiguration and PSK + Session Ticket for session resumption (0RTT or otherwise). Both mechanisms have the same properties in terms of forward secrecy: a compromise of the server's private data (whether PSK, session ticket key, or DH exponent) lets an attacker retroactively decrypt data from all sessions established with the PSK or Session Ticket. However, both mechanisms contain different language around how the lifetimes of the resumption data is managed. After some discussion with Facebook and others, I'd like to suggest a change in the wording of the draft to make the Session Ticket lifetime more closely resemble the lifetime of the ServerConfiguration. Here is the current language for session ticket lifetimes: ticket_lifetime_hint Indicates the lifetime in seconds as a 32-bit unsigned integer in network byte order from the time of ticket issuance. A value of zero is reserved to indicate that the lifetime of the ticket is unspecified. The ticket lifetime hint is informative only. A client SHOULD delete the ticket and associated state when the time expires. It MAY delete the ticket earlier based on local policy. A server MAY treat a ticket as valid for a shorter or longer period of time than what is stated in the ticket_lifetime_hint. And for SeverConfigurations: struct { opaque configuration_id<1..2^16-1>; uint32 expiration_date; KeyShareEntry static_key_share; EarlyDataType early_data_type; ConfigurationExtension extensions<0..2^16-1>; } ServerConfiguration; expiration_date The last time when this configuration is expected to be valid (in seconds since the Unix epoch). Servers MUST NOT use any value more than 604800 seconds (7 days) in the future. Clients MUST NOT cache configurations for longer than 7 days, regardless of the expiration_date. [[OPEN ISSUE: Is this the right value? The idea is just to minimize exposure.]] My proposed change is to change the session ticket lifetime hint to a strict lifetime along the lines of the ServerConfiguration: ticket_lifetime Indicates the lifetime in seconds as a 32-bit unsigned integer in network byte order from the time of ticket issuance. Servers MUST NOT use any value more than 604800 seconds (7 days). The value of zero indicates that the ticket should be discarded immediately. Clients MUST NOT cache session tickets for longer than 7 days, regardless of the ticket_lifetime. It MAY delete the ticket earlier based on local policy. A server MAY treat a ticket as valid for a shorter period of time than what is stated in the ticket_lifetime. The full change is on Github as a pull request: https://github.com/tlswg/tls13-spec/pull/424 Note that this new wording is more strict than that of RFC 5077, which does not specify a maximum lifetime for session tickets or dictate that the hint be followed in any way by either client or server. The introduction of the resumption master secret strengthened the forward secrecy story in TLS by requiring resumed connections to use new session keys. The proposed logic strengthens the forward secrecy story of TLS even further by creating a hard limit on the lifetime of unused resumption master secrets. Nick
- [TLS] Removing the "hint" from the Session Ticket… Nick Sullivan
- Re: [TLS] Removing the "hint" from the Session Ti… Benjamin Kaduk
- Re: [TLS] Removing the "hint" from the Session Ti… Subodh Iyengar
- Re: [TLS] Removing the "hint" from the Session Ti… Martin Thomson
- Re: [TLS] Removing the "hint" from the Session Ti… Russ Housley
- Re: [TLS] Removing the "hint" from the Session Ti… Salz, Rich
- Re: [TLS] Removing the "hint" from the Session Ti… Martin Rex
- Re: [TLS] Removing the "hint" from the Session Ti… Salz, Rich
- Re: [TLS] Removing the "hint" from the Session Ti… Viktor Dukhovni
- Re: [TLS] Removing the "hint" from the Session Ti… Subodh Iyengar