Re: [TLS] draft-jay-tls-psk-identity-extension-01

[David Woodhouse <[e-mail]>]

On Wed, 2016-09-21 at 23:00 +0300, Ilari Liusvaara wrote:
> On Wed, Sep 21, 2016 at 08:16:15PM +0100, David Woodhouse wrote:
> > 
> > On Wed, 2016-09-21 at 17:46 +0000, Raja ashok wrote:
> > 
> > > 
> > > [ashok] : I feel sending the selected ID is better, otherwise while
> > > process "server hello" msg, client has to maintain the PSK ID list in
> > > the same order in which it sent. Already there was a discussion in
> > > TLS1.3 group for sending selected ID instead of index. 
> > There is also discussion of supporting only a *single* PSK identity in
> > TLSv1.3. If that happens, is there a real need for the extension to
> > permit more than one identity in TLS <= 1.2. 
> Is the intended usecase some "IoT"/"embedded" devices? If so, I think
> this is *extremely* bad idea.
> 
> Those things tend to have very long lifespans, so one shouldn't put
> one out except with cutting-edge stuff. Anything less, and there is
> substantial risk of it going bad during lifetime.
> 
> It would be possible to retrofit an extension to do multiple identites
> at once into TLS 1.3 even if baseline TLS 1.3 allows only one, altough
> implementing it probably will not be pleasant.[1]

Typically I would expect that a given IoT client would still support
only one form of PSK, and offer one identifier. The update model would
be that the server accepts *either* the old or the new keys, and
clients are slowly upgraded to offer the latter. But still only one at
a time?

> [1] E.g. altering hello_finished to be a list, one entry for each
> identity, or omitting it entierely for "implicit finished with the
> used 0-RTT key before ServerHello" trick I outlined earlier.
> 
> (Neither is probably pleasant to implement... The latter is probably
> easier if the library architecture is suitable).

I had also suggested including a hello_finished only for the first
(preferred) PSK identity. If the server doesn't want that one, it can
send a HelloRetryRequest with a PreSharedKeyExtension indicating which
PSK identity it *does* want.

Or did I miss a reason why that wasn't sufficient and *each*
ClientHello needed to be validated? I confess I've only been looking at
this for the last day or so.

-- 
dwmw2