Re: [TLS] TLS 1.3 - method to request uncached shared secrets

Dave Garrett <> Sun, 19 July 2015 22:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5A2CC1B2DC1 for <>; Sun, 19 Jul 2015 15:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N6rAbWDDtaRL for <>; Sun, 19 Jul 2015 15:12:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6EDA11B2DC0 for <>; Sun, 19 Jul 2015 15:12:57 -0700 (PDT)
Received: by qgeu79 with SMTP id u79so10387157qge.1 for <>; Sun, 19 Jul 2015 15:12:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=hLq8oE9zfyaj6yotyHQ4Ap94gUS/6ceUh7W6Y4ap3BU=; b=TuW/9uNBPVJAFpyKsJfIthJC3hb22eGsRDDKVmHC7t1bGAiJxK3nXax4YV77UYJfOU sV3TrmDDYEyGbjBxj5KYxpvLGmCvy9AGySerDxW4pkMEudehnmAV7n5As3oku6OsP2oq 4ju9ZA5TUKmhVgBHcwQf5iS9PA+gdUA0RH7WY5iCsTZP4Ncpn32sNaYdSrMIb8ck4H4j pLIal/LKLaJo6cUeCqi5yMquGubjMdxwt7sfBdVKD/rAZNLtI4LSr32LKieZ0tnzljkb bEBVeorwJnC13m2AzxcI7v2XYoJrrUI3KCT9N/fVTSi87t0GtxFSH3wHp55PEroA1J3b Ykkg==
X-Received: by with SMTP id i21mr41406500qgi.4.1437343976697; Sun, 19 Jul 2015 15:12:56 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id z76sm9852587qge.22.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 19 Jul 2015 15:12:56 -0700 (PDT)
From: Dave Garrett <>
To: Brian Smith <>, Eric Rescorla <>
Date: Sun, 19 Jul 2015 18:12:54 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] TLS 1.3 - method to request uncached shared secrets
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 Jul 2015 22:12:59 -0000

On Sunday, July 19, 2015 05:28:27 pm Brian Smith wrote:
> It depends on how the server implements tickets. The server could implement
> tickets the same way that it implements session ID-based resumption. That's
> not a good idea, but I don't think the spec should prohibit that type of
> implementation either since it unenforceable. Thus, because of that
> possibility, it is valuable to have the client be able to say "don't cache
> the session" and/or limit the session's lifetime, so the client can help
> direct the level of forward secrecy for the session. Right now, only the
> server has a say in how long a session will be forward-secret.
> Note also that the NewSessionTicket extension precedes any application
> data, so without a way to prevent an unwanted NewSessionTicket message from
> being sent, the client has to waste effort and time to consume the
> NewSessionTicket before it can do anything useful.

If the general ticket lifetime request route is not needed, here's the simplest route: just don't drop the Session Ticket extension.

This keeps it with the same semantics for requesting a ticket, thus allowing TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2 servers with no additional effort. TLS 1.3 sessions would be resumed using the new PSK-based method and TLS 1.2 sessions would be resumed using the old session ticket extension.

Should I submit this as a PR? It seems like the obvious route if all we want is to just keep the ability for a client to not request a ticket. No need to write a new extension at all.