On Wed, Sep 21, 2016 at 1:33 PM, David Woodhouse <dw...@infradead.org> wrote:
> 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. > I don't see how this is appreciably easier than just having the client offer one and then the server HRR. -Ekr > > 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 > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
