On Thu, Jan 30, 2020 at 06:37:37PM -0800, Jim Schaad wrote: > > > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of Francesca Palombini > Sent: Wednesday, January 29, 2020 6:43 AM > To: Benjamin Kaduk <ka...@mit.edu>; draft-ietf-ace-oscore-prof...@ietf.org; > Ace Wg <ace@ietf.org> > Subject: Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08 > > Hi Ben, > > Thank you so much for this very thorough and in-depth review! > > I have started a PR (https://github.com/ace-wg/ace-oscore-profile/pull/25 ) > where I plan to include all the review comments. I have started with the > editorial fixes, which I have collected in one issue: > https://github.com/ace-wg/ace-oscore-profile/issues/24 > > The details of answers and additional questions for clarification are inline, > I also noted with "OK" the points where I agree with your suggestion and > don't see any problem implementing in the PR. I will keep the numbering > consistent in the mail thread and in the github to make sure everything is > covered. > > Additionally, you made a number of points I'd like to get wg opinion on: > > * The mechanism of letting the RS pick the identifier of the client is not > worth the additional complexity. So I propose we revert that, and go back to > AS MUST pick the clientId, the clientId MUST be included in the token. This > will only add some considerations about the scenario has several-AS-per-RS, > in which case these AS need to be synchronized on clientIds they give out. > (6., 21., 61., 65.) > > [JLS] For better or worse, this is not the only consideration. The above > statement presumes that only the AS is going to be assigning the client > identifiers. If the RS uses a different method of doing authentication as > well, such as LAKE, then there is a chance for collisions at that point as > well. > > * Recommendation about length of nonces N1 and N2 to use. The wg agreed on 64 > bits, now Ben suggests to use 128 bits nonces. Reminder: these nonces are > appended to the input salt to create the Master Salt, to run the HKDF and > derive the keys. Also consider that OSCORE appendix B2 has a similar setting > and does some considerations about that, mentioning that "typically nonces of > at least 8 bytes will be used". > > [JLS] I am agnostic on this, but I think that generally 64-bits from each > side is sufficient. This does add an additional 8 bytes of message size when > sending the token to the server. That worries me slightly. >
I agree that 64 bits from each endpoint may well be sufficient, but it requires some analysis and thought to verify that, whereas 128 bits is "obviously enough". So, I'd like to know what level of analysis has already been done (vs. just inference from, e.g., OSCORE). -Ben _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
