On 15/04/2019 15:38, Konda, Tirumaleswar Reddy wrote: >> -----Original Message----- From: Dots <dots-bounces@xxxxxxxx> On >> Behalf Of Stephen Farrell Sent: Monday, April 15, 2019 6:56 PM To: >> mohamed.boucadair@xxxxxxxxxx; secdir@xxxxxxxx Cc: >> draft-ietf-dots-signal-channel.all@xxxxxxxx; ietf@xxxxxxxx; >> dots@xxxxxxxx Subject: Re: [Dots] Secdir telechat review of >> draft-ietf-dots-signal-channel-31 >> >> >> Hiya, >> >> On 15/04/2019 14:16, mohamed.boucadair@xxxxxxxxxx wrote: >>>> - p13: The cuid still seems to me to be too static (there's a >>> >>> [Med] This is a feature not a bug. This scheme is particularly >>> useful to recover state, for example, upon reboot or crash of a >>> DOTS client. >>> >> >> Well, fair enough, but FWIW I'm not convinced that a client that >> can keep state (the private key and other dots stuff) couldn't also >> as easily keep a cuid value. And ISTM there should also be equally >> good ways to recommend for generating a cuid that don't have that >> 1:1 mapping to a key pair. All that said, it's not me needs to be >> convinced, but the IESG, so probably best to wait and see if they >> think this is worth changing or not before doing so. > > The advantage of the 1:1 mapping is the DOTS servers can validate the > DOTS client is not using the 'cuid' of another client. So that'd be "an" advantage, if it is one;-) But given the servers are supposed to authenticate the client via TLS client-auth (or else the server doesn't see the public key), I don't see the need. Nor do I recall that the server is supposed to compare the key to the cuid - if that check is to be done, then that'd need to be in the spec or a client that re-keys would have to make a new cuid. (Apologies if that's in the spec and I've forgotten it.) Cheers, S. > > -Tiru > >> >> S. >> >
Attachment:
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
