On 15 November 2016 at 17:34, Fossati, Thomas (Nokia - GB) <thomas.foss...@nokia.com> wrote: > The draft proposes two ways to allocate the identifier (see 3rd para of > https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1): > 1. Server decides unilaterally a value that is fixed for the duration of > the session (SecAssocType.fixed); > 2. Server and Client agree on a sequence of values generated using HOTP > [RFC 4226] seeded by the session shared secret (SecAssocType.hotp); Client > shifts to the next value when needed (e.g. on transport handover). > > > At first this might not look particularly elegant, but there are good > reasons for having both methods.
I'm not seeing quite enough information here to implement this. How does a server know which of the many HOTP keys it has are in use? Surely you can't use the same HOTP key with every client. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
