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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
