[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