Re: [TLS] extending the un-authenticated DTLS header

[Nikos Mavrogiannopoulos <[e-mail]>]

On Tue, 2016-11-15 at 18:10 +0900, Martin Thomson wrote:
> On 15 November 2016 at 17:34, Fossati, Thomas (Nokia - GB)
> <[e-mail]> 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.

Not sure I understand the question, but I'd suggest to read the text on
generating the hotp keys.

regards,
Nikos