Re: [TLS] Comments on the session ticket format in TLS 1.3

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 12 March 2017 23:48 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF0D12940C for <tls@ietfa.amsl.com>; Sun, 12 Mar 2017 16:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 MP9WVY8UVDXS for <tls@ietfa.amsl.com>; Sun, 12 Mar 2017 16:48:45 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD4A126D74 for <tls@ietf.org>; Sun, 12 Mar 2017 16:48:45 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 4F6697A32F1 for <tls@ietf.org>; Sun, 12 Mar 2017 23:48:44 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CANHgQ8Gu5wDMq7dPmVSLH=rr03dN7OaY-aBXUp9P=jSji+kURA@mail.gmail.com>
Date: Sun, 12 Mar 2017 19:48:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <36717367-120F-4259-A692-638243647071@dukhovni.org>
References: <CANHgQ8EEJeTVvyQH8SosO4M3Ecz2=ZE-UPGndcu=XfB1f+1Zgg@mail.gmail.com> <CABkgnnXWNoGyx4m+sVdqu4vZUi3SWgPFZKndxpM35ezH+mnwpQ@mail.gmail.com> <CANHgQ8Gu5wDMq7dPmVSLH=rr03dN7OaY-aBXUp9P=jSji+kURA@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/p6g1BD8SMsc5X_a9mo_2O1q2fjo>
Subject: Re: [TLS] Comments on the session ticket format in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
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: Sun, 12 Mar 2017 23:48:46 -0000

> On Mar 12, 2017, at 7:23 PM, Ivan Ristic <ivan.ristic@gmail.com> wrote:
> 
> Another example, perhaps relevant: load balancers can often be configured to use sticky sessions based on TLS session IDs. It's a useful feature given that web servers typically don't have a good story for distributed server-side TLS session storage. Without an explicit ID, they too would need to make their own.

With session tickets, there's no need for server-side TLS session storage,
and no need for load-balancers to direct resuming TLS clients to the same
server.  All that's required is proper coordination of the distribution
and rotation of the short-term session ticket encryption keys.  This
improves the effectiveness of the load-balancer when some clients are
responsible for a large fraction of the load.

Opaque session tickets are just fine, and one can tell which connections
are reused by observing abbreviated handshakes.

For example, Gmail's SMTP servers all share the same session ticket encryption
keys, and any server can resume a session initiated by a different server.

Here's an example, in which an SMTP TLS client reuses a session with a
second Gmail SMTP server (w51si13238472qtb.292) 10 seconds after the
session is created with a first SMTP server (r3si13266009qkb.62):

$ posttls-finger -lmay -Lcache,summary -m 3 -r 10 gmail.com
posttls-finger: Connected to gmail-smtp-in.l.google.com[209.85.144.27]:25
posttls-finger: < 220 mx.google.com ESMTP r3si13266009qkb.62 - gsmtp
posttls-finger: > EHLO straasha.imrryr.org
posttls-finger: < 250-mx.google.com at your service, [108.21.89.116]
...
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: looking for session [209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16 in memory cache
posttls-finger: save session [209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16 to memory cache
posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[209.85.144.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
posttls-finger: > EHLO straasha.imrryr.org
posttls-finger: < 250-mx.google.com at your service, [108.21.89.116]
...
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 closing connection r3si13266009qkb.62 - gsmtp
posttls-finger: Reconnecting after 10 seconds
<...10 second delay...>
posttls-finger: < 220 mx.google.com ESMTP w51si13238472qtb.292 - gsmtp
posttls-finger: looking for session [209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16 in memory cache
posttls-finger: reloaded session [209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16 from memory cache
posttls-finger: gmail-smtp-in.l.google.com[209.85.144.27]:25: Reusing old session
posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[209.85.144.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 closing connection w51si13238472qtb.292 - gsmtp
posttls-finger: Found a previously used server.  Done reconnecting.

-- 
-- 
	Viktor.