IETF Logo Mail Archive

Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

Benjamin Kaduk <kaduk@mit.edu> Tue, 30 June 2020 16:25 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC443A0D2C; Tue, 30 Jun 2020 09:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdCPPmgUQZWk; Tue, 30 Jun 2020 09:25:11 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35643A0D32; Tue, 30 Jun 2020 09:24:39 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05UGOYU1002966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 12:24:37 -0400
Date: Tue, 30 Jun 2020 09:24:34 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Carsten Bormann <cabo@tzi.org>
Cc: Olaf Bergmann <bergmann@tzi.org>, draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org
Message-ID: <20200630162434.GM58278@kduck.mit.edu>
References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> <20200527234227.GD58497@kduck.mit.edu> <87r1uczgyq.fsf@wangari> <20200629224537.GX58278@kduck.mit.edu> <87mu4konya.fsf@wangari> <DB603021-7A82-4A30-BE07-C2D913E1C32F@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DB603021-7A82-4A30-BE07-C2D913E1C32F@tzi.org>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/lrSpL4-cNEadae5nqgMks2Qlx6Y>
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2020 16:25:22 -0000

On Tue, Jun 30, 2020 at 04:21:34PM +0200, Carsten Bormann wrote:
> On 2020-06-30, at 12:19, Olaf Bergmann <bergmann@tzi.org> 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.

-Ben

v2.23.0 | Report a Bug | By Email