> -----Original Message----- > From: Benjamin Kaduk <[email protected]> > Sent: Tuesday, June 30, 2020 9:25 AM > To: Carsten Bormann <[email protected]> > Cc: Olaf Bergmann <[email protected]>; draft-ietf-ace-dtls- > [email protected]; [email protected] > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > On Tue, Jun 30, 2020 at 04:21:34PM +0200, Carsten Bormann wrote: > > On 2020-06-30, at 12:19, Olaf Bergmann <[email protected]> wrote: > > > > > > NEW: > > > > > > All CBOR data types are encoded in canonical CBOR as defined in > > > Section 3.9 of {{RFC7049}}. This implies in particular that the > > > `type` and `L` components use the minimum length encoding > > > > Note that 7049bis, which has been submitted to IESG already, all but > deprecates this and replaces this with “deterministic encoding”. There is > only > one actual technical change, which is about map ordering. Also, please check > whether “preferred encoding” would actually be enough. > > > > I would generally prefer to avoid the need for deterministic/canonical > encoding — is there really a need to re-encode the token? > > My original comment was in the context of a novel data structure being used as > HKDF input, which has 'type' and 'L' fields unrelated to any preexisting > token. > Using the 'access_token' map as transmitted would be helpful, but is not > sufficient.
If you are not doing a re-encoding of the token, then I believe that preferred serialization and deterministic serialization are going to generate the same answer. With the map being used then this is not true, and it is also true that the change in map ordering will hit this. This is a piece of the document that I have never implemented because I just don't believe that this option is a reasonable thing to require being done so I missed the fact that the original encoded token is not being used. There is a possible DOS attack by a MITM changing the encoding on the token since it is not protected when posted to the RS. If this is going to be changed, I would say use the binary string encoding from the bstr of the inner most COSE wrapping layer as the input to minimize this. Jim > > -Ben _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
