Re: [TLS] Pre_shared_key Extension Question

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 09 September 2016 14:45 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 0064612B120 for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 07:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.109
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LmTFLJ_V3ZN for <tls@ietfa.amsl.com>; Fri, 9 Sep 2016 07:45:05 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C710D12B122 for <tls@ietf.org>; Fri, 9 Sep 2016 07:45:04 -0700 (PDT)
Received: from [192.168.91.132] ([80.92.121.21]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MY86C-1bV9cE0Ibo-00UnrL; Fri, 09 Sep 2016 16:45:02 +0200
To: Eric Rescorla <ekr@rtfm.com>
References: <fa85eafb-b2f5-b5c2-859a-a2e24d734324@gmx.net> <CABcZeBOBffGU6RWgfMkRhqzxLd-yUw0v_CoUvtdDyTR0Ubvm6A@mail.gmail.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Message-ID: <4f35e86c-cec0-37a8-3f21-70cc0014c0ea@gmx.net>
Date: Fri, 09 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: <CABcZeBOBffGU6RWgfMkRhqzxLd-yUw0v_CoUvtdDyTR0Ubvm6A@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/tls/wcHZfnG2iUYDt38fcRTG-E3s-G8>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Pre_shared_key Extension Question
X-BeenThere: tls@ietf.org
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." <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: 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 
seems.

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.
"

Ciao
Hannes


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
> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> 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
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>