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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
