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