[TLS] TLS1.3 + PSK with multiple identities

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 08 August 2016 08:17 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A79DD12D501 for <tls@ietfa.amsl.com>; Mon, 8 Aug 2016 01:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.149
X-Spam-Status: No, score=-8.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LIP9fA_G2l9G for <tls@ietfa.amsl.com>; Mon, 8 Aug 2016 01:17:43 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC24128874 for <tls@ietf.org>; Mon, 8 Aug 2016 01:17:43 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B04A9C05681D for <tls@ietf.org>; Mon, 8 Aug 2016 08:17:42 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u788Helh015652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <tls@ietf.org>; Mon, 8 Aug 2016 04:17:42 -0400
Message-ID: <1470644260.3026.13.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: "tls@ietf.org" <tls@ietf.org>
Date: Mon, 08 Aug 2016 10:17:40 +0200
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com []); Mon, 08 Aug 2016 08:17:42 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5KH514VqokoRPXsaOv3IrZI4gMg>
Subject: [TLS] TLS1.3 + PSK with multiple identities
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: Mon, 08 Aug 2016 08:17:45 -0000

 I'm reading the "Pre-Shared Key Extension" section of the TLS 1.3
draft [0], and I noticed quite some deviations (IMO) from typical TLS
protocol behavior. No rationale is given about them so I ask on list.

To summarize, the client sends a list of identitities and the server
replies with an index indicating which identity is approved.

1. The server reply with an index is unique in TLS. It is not used in
ciphersuite selection or in any other negotiation in TLS where the
client sends multiple options. Why not have the server reply with the
selected username.

2. Why does the client send multiple identities? In TLS-SRP a single
identity is sent, and the same in the existing TLS-PSK rfc. How is this
envisioned to be used? A client sends: I'm probably one of Bob, Nikos,
George, take a look on that list and tell me who I really am? In that
case why not allow the server, to reply with a username outside that
list (i.e., assign a new one to be used at the next session - see point

3. The maximum size of the username is 2^16. Isn't that excessive for a
user name or a user identifier? Why not set 2^8? That would fit a uuid
or anything similarly large.


[0]. https://tlswg.github.io/tls13-spec/#rfc.section.4.2.5