Re: [Ace] I-D Action: draft-ietf-ace-cmpv2-coap-transport-01.txt

David von Oheimb <David.von.Oheimb@siemens.com> Thu, 29 April 2021 13:34 UTC

Return-Path: <David.von.Oheimb@siemens.com>
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 3E0313A3EE1 for <ace@ietfa.amsl.com>; Thu, 29 Apr 2021 06:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.917
X-Spam-Level:
X-Spam-Status: No, score=-6.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 MQwp5fvQUc38 for <ace@ietfa.amsl.com>; Thu, 29 Apr 2021 06:34:18 -0700 (PDT)
Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (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 333363A3EE6 for <ace@ietf.org>; Thu, 29 Apr 2021 06:34:17 -0700 (PDT)
Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 13TDYE9T014334 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Apr 2021 15:34:14 +0200
Received: from [139.22.38.45] ([139.22.38.45]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 13TDUZdB024225; Thu, 29 Apr 2021 15:30:35 +0200
To: Mohit Sahni <mohit06jan@gmail.com>, "ace@ietf.org" <ace@ietf.org>
Cc: "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>, Andreas Kretschmer <Andreas.Kretschmer@siemens.com>, stripathi@paloaltonetworks.com
References: <AM0PR10MB24186B276EBD30EE32A7A87BFE969@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM> <CAEpwuw167FdJzQYLK2ZV0B_6=2edV+wj9zKDnpbiN-0aTgNL=g@mail.gmail.com> <4f9d9e3f-be6a-9fe7-40b2-1f018df1742a@siemens.com> <ea9d4f16-8744-c757-6b81-f22b3ff77e5d@siemens.com> <CAEpwuw2z=5L_szZihL2giz80dfT+Bx3T2C8tN8LJP-Ro2bgSoA@mail.gmail.com>
From: David von Oheimb <David.von.Oheimb@siemens.com>
Message-ID: <a300bc62-987c-19d0-6a36-e73a1ca17988@siemens.com>
Date: Thu, 29 Apr 2021 15:30:35 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <CAEpwuw2z=5L_szZihL2giz80dfT+Bx3T2C8tN8LJP-Ro2bgSoA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------5C74F9ECA5D20CFB7B19038F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/lLwZIK8go7MWICdkm0eXGGe6MOo>
Subject: Re: [Ace] I-D Action: draft-ietf-ace-cmpv2-coap-transport-01.txt
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: Thu, 29 Apr 2021 13:34:23 -0000

Hi Mohit,

a couple of comments for the WGLC also from my side.

 0. Abstract:

    IMO it would be nice (but it's of course not strictly needed) to
    refer to the Lightweight CMP profile already in the abstract,
    maybe this way after the first sentence:

         It details the CoAP transfer option mentioned in the Lightweight CMP Profile.

 1. Section 1:

    encryption of messages -> protection of messages    (because
    authenticity is the predominant requirement)

    between CAs -> between RAs                          (between CAs
    makes little sense, but there may be more than one RA involved)

 2. Section 2.6:

    the Block-Wise transfer [RFC7959 <https://tools.ietf.org/html/rfc7959>] mode
       MUST be used for the CMP Transactions over CoAP

    I do not have a strong opinion here, but I fear that strictly
    requiring block-wise transfer may needlessly exclude simple
    implementations,
    which may be sufficient in scenarios where the payloads are known to
    be rather small.
    Writing SHOULD or RECOMMENDED would state that implementors can
    deviate from the recommendation,
    but only if they are aware of the consequences and are willing to
    cope with them.
    So what you could do - if others agree - is to replace

       In order to avoid IP fragmentation of messages exchanged
       between EEs and RAs or CAs, the Block-Wise transfer [RFC7959 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7959&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7C9d2a8b2f3d184b9897e508d90b0cf135%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637552972467884509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ukHaAdsU7gvXCCVKMDqwL6JA%2FvbPcICBT7Srwc0OR1g%3D&reserved=0>] mode
       MUST be used for the CMP Transactions over CoAP.

    by a strengthened recommendation with a motivation/warning, e.g.,

       Block-wise transfer [RFC7959 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7959&data=04%7C01%7C3fc86e35-ce5e-4719-beb0-5253a4681d60%40ad011.siemens.com%7C9d2a8b2f3d184b9897e508d90b0cf135%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637552972467884509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ukHaAdsU7gvXCCVKMDqwL6JA%2FvbPcICBT7Srwc0OR1g%3D&reserved=0>] mode
       SHOULD be used for the CMP Transactions over CoAP.
       This is strongly recommended to avoid IP fragmentation of messages
       and the block-wise option is a critical option as per RFC 7959.

 3. Section 3:

    Nice to see that you streamlined the text regarding DTLS.

 4. Section 4:

    cross protocol proxy -> cross-protocol proxy

    pre configured servers -> pre-configured servers

 5. Section 5:

     In order to protect themselves against DDoS attacks, the
       implementations SHOULD avoid sending or receiving very small packets
       containing partial CMP PKIMessage data.

    Sounds good, but the point is not distributed DoS (only) but DoS in
    general, so: DDoS -> DoS
    and there is no real protection against DoS, just reduction of risks
    they impose.
    Moreover, the recipient has little influence on the size of packets.
    I'd further suggest streamlining the sentence, arriving at, e.g.,:

    "In order to reduce the risks imposed by DoS attacks,
    implementations SHOULD minimize fragmentation of messages,
    i.e., avoid packets containing partial CMP PKIMessage data."

    And better starting a new paragraph thereafter because using a
    CoAP-to-HTTP proxy is a different topic.

Regards,

    David