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.
Also, has anyone done security analysis of doing PSK negotiation that
way in TLS 1.2 (someone has clearly done that for TLS 1.3, given
some of the attacks posted)...
 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).
TLS mailing list