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

On Wed, Sep 21, 2016 at 1:33 PM, David Woodhouse <dwmw2@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
>
>