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

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 08 Aug 2016 10:17:40 +0200

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.

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

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.

regards,
Nikos

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 8 Aug 2016 11:28:37 +0300

> client sends multiple options. Why not have the server reply with the

More compact and makes the option where server sends some bad option
more clear.
 
> list (i.e., assign a new one to be used at the next session - see point

You already need multiple if you try to "resume"[1] DHE-PSK session
(since "resumption" shares the PSK space).

Additionally, TLS 1.2 had identity hint, but TLS 1.3 eliminates that
due to flight limits.

> or anything similarly large.

If one wants to do the equivalent of tickets in TLS 1.2, one needs
pretty large usernames.

[1] IMO, TLS 1.3 does not have session resumption (doesn't stop others
from calling the relevant features "resumption").

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 08 Aug 2016 11:20:42 +0200

> More compact and makes the option where server sends some bad option

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.

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

> If one wants to do the equivalent of tickets in TLS 1.2, one needs

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

regards,
Nikos