Re: [TLS] TLS1.3 + PSK with multiple identities

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

Return-Path: <nmav@redhat.com>
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 2B3EF12D150 for <tls@ietfa.amsl.com>; Mon, 8 Aug 2016 02:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.149
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBDjiVeW6-Vj for <tls@ietfa.amsl.com>; Mon, 8 Aug 2016 02:20:45 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7519127071 for <tls@ietf.org>; Mon, 8 Aug 2016 02:20:45 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 101744E328; Mon, 8 Aug 2016 09:20:45 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.68]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u789KgTn019873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 8 Aug 2016 05:20:44 -0400
Message-ID: <1470648042.3026.44.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Mon, 08 Aug 2016 11:20:42 +0200
In-Reply-To: <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi>
References: <1470644260.3026.13.camel@redhat.com> <20160808082836.jgq7a4qqvis6msp5@LK-Perkele-V2.elisa-laajakaista.fi>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 08 Aug 2016 09:20:45 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xKJOnp0Hw5qA0GnI9PXQ7ylERgM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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 09:20:47 -0000

On Mon, 2016-08-08 at 11:28 +0300, Ilari Liusvaara wrote:
> On Mon, Aug 08, 2016 at 10:17:40AM +0200, Nikos Mavrogiannopoulos
> wrote:
> > 
> > Hello,
> >  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.
> 
> More compact and makes the option where server sends some bad option
> more clear.

I'm not sure about being more clear. What I immediately notice is that
it requires the client to remember not only the values that it sent,
but also the indexes. I guess that's no big deal, but it is used
nowhere else in TLS.

> > 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
> > 1).
> You already need multiple if you try to "resume"[1] DHE-PSK session
> (since "resumption" shares the PSK space).

That's very awkward. That way the protocol mandates code like:

if (!id_in_resumption_db()) {
    if (!valid_ticket())
      if (!try_find_user_in_psk_userfile())
        proceed_with_random_psk(); /* hide the fact that username
doesn't exist in db */
}

which is not really sane code. Not only that, but servers who would
like to prevent valid username testing in their PSK key file as above,
would be forced to make resumption attempts with unknown or long-
expired tickets fail.

A protocol must have clarity on the data sent on the wire and their
purpose. Cross protocol attacks work by exploiting data which may be
interpreted in multiple ways and such generic purpose identifiers seem
to be like a good candidate for that.

I think at minimum identities known to the protocol (e.g., resumption)
should be distinguishable from PSK usernames. The draft leaves that to
the server implementor to do, but I do think such identifiers should be
tagged at the protocol level since it affects all implementations.

> 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.
> If one wants to do the equivalent of tickets in TLS 1.2, one needs
> pretty large usernames.

I find that, as another unfortunate side-effect of combining unrelated
protocol fields.

regards,
Nikos