Re: [TLS] Pre_shared_key Extension Question

Hannes Tschofenig <> Fri, 09 September 2016 14:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0064612B120 for <>; Fri, 9 Sep 2016 07:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.109
X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0LmTFLJ_V3ZN for <>; Fri, 9 Sep 2016 07:45:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C710D12B122 for <>; Fri, 9 Sep 2016 07:45:04 -0700 (PDT)
Received: from [] ([]) by (mrgmx003) with ESMTPSA (Nemesis) id 0MY86C-1bV9cE0Ibo-00UnrL; Fri, 09 Sep 2016 16:45:02 +0200
To: Eric Rescorla <>
References: <> <>
From: Hannes Tschofenig <>
Message-ID: <>
Date: Fri, 9 Sep 2016 16:45:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:j1l65sJfTbjyrsXtLCFYr61gK7JJWI6Q4FpzvpiHyyfcq3WonJ5 tlx0fWdfRe1q/9fC856xqfcqHQfktRFrJ/u+gNxyV9+2Xhy+f49BT9C75H55d+MQ4yO0VZP S65fk7dLYNFfgQFxbM6kcKpnaEI3P28/qCXDFvV9RufnW6ShtZ5vwIEd8cVtpJU2OOEXif0 bXys1q3qfB8BUPfhJ2E9w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:zZOah02g2EE=:WsWdblY8Duh0YHj4dJsbUA jmTqRkPUskdGRZj1EeCUQnp8K8JKLfRHVlwtxAN0iym2kM3MO7XbUpjhBC/x8r8Wulqo7fEfY DZMItfmZexWEH4fIscy5kr+x5LV5XMknjBs5c+houuzRgh1JJ99MCKH7fHfI1W1Q2R1be94Gu Bopx4uDo63jEmsPfxwY/qzROz8U/G52tSozr8X0JAHG0jqz50SrK91pmXxWvBsFkVCuENUV1W oebjL7DjdnV48CC3O7FdZcVfM4YuLxneu2WXkdbVg2TUu3O8qdFAOniuH8tCFVS+BJa7zeeFd bh+bpmtcteyBZrdiPKiMgeyZ8SUxyw7+e342zhH2GnPCrJ5t35jq8WYOm0Pki+q9/U8NRkdi3 r/vG11ROgn+RrzVC+D6oPyqaGnSFK1Sah/IsodsOUVuSU4v8q+UPBW0iVN1mb/W8d6r6EQCzW najZ9uB8Xoe1VC6x35mz6mW5v3Y+KOeRL9/x75ecQbYcKJUF2BDt4HfVgqg1qDtLpY/+ZlDWy ZCcL1qC0VqepJwPF2jZlcDS0qEw1211iOP6aUsRzT7xTdVcOptJ/Ro3AJ3w0AirqfSV41PqXw 5iLZfqPkdFJBgu59ehCJSGaCgJzh+K0voN7rK7StsgN8H+zLDSQQaS+QBizQGXvupvXnX33uV kgToYoORVUou98aRIDdnx3gJbldtNUnZPaMULlhZn7dJsBYVZibJ+uCB9jW2I5Aj1QseCk40x qPoBvKhsg/uPqnPr+RQgoKKzrFLrrE+Ip6qrdgIf9UOrt+HDGx4NfAPJISF7Ua9j1tudUksIO bGAwD9z
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] Pre_shared_key Extension Question
X-Mailman-Version: 2.1.17
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: Fri, 09 Sep 2016 14:45:10 -0000

Hi Ekr,

thanks for the response.

The psk_identity_hint in RFC 4279 was sent from the server to the client 
and was a mechanism that was believed to be needed by the 3GPP in their 
bootstrapping architecture, which in the end was never widely used (as 
far as I know). So, not necessarily a super important features, as it 

As mentioned in my other mail regarding sending the ticket together with 
the long-term PSK identity could be addressed better by clarifying the 
server is intending to keep the ticket cached for the time indicated in 
ticket_lifetime (rather than saying the opposite which may lead 
implementers to care less).

Hence, I would mind if you delete the following two sentences in Section 
4.5.1 "New Session Ticket Message":

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.


On 08/18/2016 12:17 AM, Eric Rescorla wrote:
> The intention here was to compensate for not having psk_identity_hint.
> However, it also allows you to do resumption of PSK-established sessions.
> It would be a fairly significant simplification to say you could only
> have one PSK, because then we could easily require the client to prove
> knowledge of the key, for instance by stuffing a MAC at the end of the
> ClientHello as we discussed in Berlin.
> So:
> Is there any demand for multiple identities? I do not believe there is
> any in the Web context. If not, we should remove this feature.
> -Ekr
> On Thu, Aug 11, 2016 at 1:39 AM, Hannes Tschofenig
> < <>> wrote:
>     Hi all,
>     the currently defined “pre_shared_key” extension allows clients to send
>     a list of the identities. I was wondering in what use cases this is
>     useful and what policy guides the server to pick the most appropriate
>     psk identity. I couldn't find any discussion in the document about this
>     aspect.
>     Ciao
>     Hannes
>     _______________________________________________
>     TLS mailing list
> <>
>     <>