Re: [Ace] Lars Eggert's No Objection on draft-ietf-ace-dtls-authorize-16: (with COMMENT)

Stefanie Gerdes <gerdes@tzi.de> Tue, 11 May 2021 12:42 UTC

Return-Path: <gerdes@tzi.de>
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 922253A1639; Tue, 11 May 2021 05:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 CGyVD3ZtziJQ; Tue, 11 May 2021 05:42:16 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8CE3A165A; Tue, 11 May 2021 05:42:16 -0700 (PDT)
Received: from [192.168.0.48] (p5b36f986.dip0.t-ipconnect.de [91.54.249.134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Ffcxy0xqtz315f; Tue, 11 May 2021 14:42:14 +0200 (CEST)
To: Lars Eggert <lars@eggert.org>, The IESG <iesg@ietf.org>
Cc: draft-ietf-ace-dtls-authorize@ietf.org, ace-chairs@ietf.org, ace@ietf.org
References: <161660861757.9999.12743279121890521978@ietfa.amsl.com>
From: Stefanie Gerdes <gerdes@tzi.de>
Message-ID: <4078cae9-55de-9232-15ed-40b4e8fa456e@tzi.de>
Date: Tue, 11 May 2021 14:42:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <161660861757.9999.12743279121890521978@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/GUTp9Y0ZgUiydvTkQjHJ4-ft02M>
Subject: Re: [Ace] Lars Eggert's No Objection on draft-ietf-ace-dtls-authorize-16: (with COMMENT)
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, 11 May 2021 12:42:27 -0000

Hi Lars,

Thank you for your detailed comments, and sorry for the late reply. We
addressed the issues as suggested. Sorry for the late reply.

Thank you for your time,
Steffi


On 3/24/21 6:56 PM, Lars Eggert via Datatracker wrote:
> Lars Eggert has entered the following ballot position for
> draft-ietf-ace-dtls-authorize-16: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 3.4, paragraph 4, comment:
>>    The resource server MUST only accept an incoming CoAP request as
>>    authorized if the following holds:
> 
> "MUST only" is odd, suggest to rephrase. (See below.)
> 
> -------------------------------------------------------------------------------
> All comments below are very minor change suggestions that you may choose to
> incorporate in some way (or ignore), as you see fit. There is no need to let me
> know what you did with these suggestions.
> 
> Section 11.1, paragraph 12, nit:
>>    [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
>>               RFC 8152, DOI 10.17487/RFC8152, July 2017,
>>               <https://www.rfc-editor.org/info/rfc8152>.
> 
> Unused Reference: 'RFC8152' is defined on line 1144, but no explicit reference
> was found in the text
> 
> Section 11.1, paragraph 16, nit:
>>    [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
>>               "Transport Layer Security (TLS) Session Resumption without
>>               Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
>>               January 2008, <https://www.rfc-editor.org/info/rfc5077>.
> 
> Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by
> RFC 8446)
> 
> Section 11.1, paragraph 22, nit:
>>    [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
>>               "Object Security for Constrained RESTful Environments
>>               (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
>>               <https://www.rfc-editor.org/info/rfc8613>.
> 
> Unused Reference: 'RFC8613' is defined on line 1208, but no explicit reference
> was found in the text
> 
> Section 3.2.2, paragraph 3, nit:
> -    To be consistent with [RFC7252] which allows for shortened MAC tags
> +    To be consistent with [RFC7252], which allows for shortened MAC tags
> +                                   +
> 
> Section 3.3.2, paragraph 3, nit:
> -    be consistent with the recommendations in [RFC7252] a client is
> +    be consistent with the recommendations in [RFC7252], a client is
> +                                                       +
> 
> Section 3.4, paragraph 4, nit:
> -    The resource server MUST only accept an incoming CoAP request as
> -                             ^^^^
> -    authorized if the following holds:
> -                                ^^ --
> +    The resource server MUST NOT accept an incoming CoAP request as
> +                             ^^^
> +    authorized if any of the following fail:
> +                  +++++++              ^^^
> 
> Section 7.1, paragraph 3, nit:
> -    [RFC7925] requires clients to decline any renogiation attempt.  A
> -                                                  ^
> +    [RFC7925] requires clients to decline any renegotiation attempt.  A
> +                                                 ++ ^
> 
> 
>