Re: [Tsv-art] Tsvart last call review of draft-ietf-ace-key-groupcomm-17
Vidhi Goel <vidhi_goel@apple.com> Wed, 03 January 2024 02:04 UTC
Return-Path: <vidhi_goel@apple.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617EFC151980 for <tsv-art@ietfa.amsl.com>; Tue, 2 Jan 2024 18:04:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.404
X-Spam-Level:
X-Spam-Status: No, score=-4.404 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3cFOQ1rPblQ for <tsv-art@ietfa.amsl.com>; Tue, 2 Jan 2024 18:04:32 -0800 (PST)
Received: from rn-mailsvcp-mx-lapp03.apple.com (rn-mailsvcp-mx-lapp03.apple.com [17.179.253.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFEDEC18DBA4 for <tsv-art@ietf.org>; Tue, 2 Jan 2024 18:04:32 -0800 (PST)
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-mx-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S6N00CT0XRJEM00@rn-mailsvcp-mx-lapp03.rno.apple.com> for tsv-art@ietf.org; Tue, 02 Jan 2024 18:04:32 -0800 (PST)
X-Proofpoint-GUID: DszwKarRKQwLvybauahysAFiUp6Os9B3
X-Proofpoint-ORIG-GUID: DszwKarRKQwLvybauahysAFiUp6Os9B3
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2024-01-02_10:2024-01-02, 2024-01-02 signatures=0
X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 malwarescore=0 spamscore=0 mlxscore=0 mlxlogscore=999 phishscore=0 adultscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401030014
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=bJFsBSIseBrCmYk/idJXa4pb1VObIfN/S95VD7BslUk=; b=OhO6eRhT8/9H3hk1urr8DewcxA05B50UUfMPbEmc5VBJcLoVtt2mpm7ztZAQT/RdshMa NAqXKUIiNepwtP4uvznug91YEWvhC1MkhYX248lKB4MSAZ7h27lhR+vLjCpFjyrwq/rC 3bL/sZDV6IokzcWcj1Zg3QADSWmMbQRJBzeZT4szSX72pgUbloXJHjmn/yU6xLVxocQt KUf14qG7LtWs70TdznNpqg6JTsB2NWeDflWD1oBIT+9F4Yx8nWmN1qsL0xEQlim5ANTv +15fKaiYIPktmdBU+0n2wqLWBG7pPTfhDCQeRIA3q3Xi4uW3l7wScZX41mwgOq1jAxw0 5w==
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0S6N0025LXRIIU50@rn-mailsvcp-mta-lapp04.rno.apple.com>; Tue, 02 Jan 2024 18:04:30 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0S6N00J00XOYDJ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 02 Jan 2024 18:04:30 -0800 (PST)
X-Va-A:
X-Va-T-CD: 4f958f8a991c53a5748b514c6554d953
X-Va-E-CD: ac5c3315158299acd3dc89308b276bf5
X-Va-R-CD: a09e0f9349997470734d8bd3d6bff788
X-Va-ID: 70f768c9-023a-4f4f-b876-f1adc21a5ab4
X-Va-CD: 0
X-V-A:
X-V-T-CD: 4f958f8a991c53a5748b514c6554d953
X-V-E-CD: ac5c3315158299acd3dc89308b276bf5
X-V-R-CD: a09e0f9349997470734d8bd3d6bff788
X-V-ID: 0f34521d-c29e-47c5-8f97-79d323fa38d5
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.619, 18.0.997 definitions=2024-01-02_10:2024-01-02, 2024-01-02 signatures=0
Received: from smtpclient.apple (vmini.scv.apple.com [17.192.154.43]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0S6N00PISXRHAX00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 02 Jan 2024 18:04:29 -0800 (PST)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <C3AF5F8A-6425-40A3-88A5-F2489F0DE059@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_F4BB481C-AC60-4FC1-A811-63D1092EE732"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.700.2\))
Date: Tue, 02 Jan 2024 18:04:19 -0800
In-reply-to: <82c4a5a1-2d0c-4f79-a692-e9eb93f8cad2@ri.se>
Cc: tsv-art@ietf.org, ace@ietf.org, draft-ietf-ace-key-groupcomm.all@ietf.org, last-call@ietf.org, Francesca Palombini <francesca.palombini@ericsson.com>
To: Marco Tiloca <marco.tiloca=40ri.se@dmarc.ietf.org>
References: <169726362973.17848.3432356979064142199@ietfa.amsl.com> <82c4a5a1-2d0c-4f79-a692-e9eb93f8cad2@ri.se>
X-Mailer: Apple Mail (2.3731.700.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/GqAniVsODpfNhaVotGXXlSxyhxo>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-ace-key-groupcomm-17
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jan 2024 02:04:37 -0000
Thanks Marco, I am fine with your provided resolutions/explanations. After the PR is merged and a new draft version is published, this draft is “Ready” with respect to my review (transport perspective). Vidhi > On Dec 15, 2023, at 8:22 AM, Marco Tiloca <marco.tiloca=40ri.se@dmarc.ietf.org> wrote: > > Hello Vidhi, > > Thanks a lot for your review! Please find in line below our detailed replies to your comments. > > A Github PR where we have addressed your comments is available at [PR]. > > Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews), and to submit the result as version -18 of the document. > > Thanks, > /Marco > > [PR] https://github.com/ace-wg/ace-key-groupcomm/pull/157 > > On 2023-10-14 08:07, Vidhi Goel via Datatracker wrote: >> Reviewer: Vidhi Goel >> Review result: Ready with Nits >> >> This document has been reviewed as part of the transport area review team's >> ongoing effort to review key IETF documents. These comments were written >> primarily for the transport area directors, but are copied to the document's >> authors and WG to allow them to address any issues raised and also to the IETF >> discussion list for information. >> >> When done at the time of IETF Last Call, the authors should consider this >> review as part of the last-call comments they receive. Please always CC >> tsv-art@ietf.org <mailto:tsv-art@ietf.org> if you reply to or forward this review. >> >> As I am not very familiar with this topic, most of my comments are editorial >> except a few. My comments are only suggestions to improve the text and I'd >> happy to discuss them if needed. >> >> COMMENTS: >> Section 1.1 : “NODENAME: the invariant once established text string used in >> URIs to identify a member a group.” >> Typo at the end of the sentence. >> >> OLD: to identify a member a group. >> NEW: to identify a member of a group. > > ==>MT > > Fixed as part of the now merged PR 156, see https://github.com/ace-wg/ace-key-groupcomm/pull/156 > > <== > >> >> Section 2: “Client (C): node that wants to join a group and take part in group >> communication with other group memebrs.” Typo in the last word- members. > > ==>MT > > Fixed as part of the now merged PR 156, see https://github.com/ace-wg/ace-key-groupcomm/pull/156 > > <== > >> >> Section 2: “Examples of a Dispatcher are:” >> Does this need to include anycast addresses? > > ==>MT > > That would be another example of dispatcher, yes. However, in order to not overload the (already too long) text, we don't think that we should be adding it here. > > <== > >> >> Section 3.3.1:”in the groups indicated by the transferred acces token as per >> its 'scope' claim” >> Typo in the word - access. > > ==>MT > > Fixed as part of the now merged PR 156, see https://github.com/ace-wg/ace-key-groupcomm/pull/156 > > <== > >> >> Section 4.1: >> For all the resources defined, can authors double check if “Clients may be >> authorized to access this resource even without being group members” is >> mentioned for all applicable resources. > > ==>MT > > Good point - we have now added a similar sentence to the /ace-group resource, see https://github.com/ace-wg/ace-key-groupcomm/commit/73c9f7e6b4aab628a185b3ff0d7acc960910a5eb > > <== > >> >> Section 4.1.2: “If the request includes unknown or non-expected fields, the >> handler MUST silently ignore them and continue processing the request.” >> Is this >> safe to silently ignore such requests? Please double check. > > ==>MT > > We believe this is ok as-is. > > The mentioned sentence comes after a much harder check for malformed messages (due, e.g., to expected fields that are missing). Also, it is followed by a sentence that allows application profiles to be stricter and react with an error in the presence of unexpected/unknown fields. > > <== > >> >> Section 4.2.1.1. “In case the joining node only knows the group identifier of >> the group it wishes to join or about which it wishes to get update information >> from the KDC” >> >> Did you mean to say “.. to get updated information..”? > > ==>MT > > Yes, now fixed: https://github.com/ace-wg/ace-key-groupcomm/commit/5278dc8d6c97533bf38baa7c6a1677d3bccc3604 > > <== > > >> >> >> Section >> 4.4.1.1. Is it possible to include an example of authentication credential >> request-response for more than 1 group members? > > ==>MT > > Sure, now changed: https://github.com/ace-wg/ace-key-groupcomm/commit/3c8ce8059965da37e647678198e7168edd0868ef > > <== > >> >> Section 5: >> >> OLD: “…if it acts as repository of authentication credentials for group >> members.” NEW: “…if it acts as a repository of authentication credentials for >> group members.” >> >> Similar text “KDC acts as repository” is present elsewhere and can be updated >> like above. > > ==>MT > > Now fixed: https://github.com/ace-wg/ace-key-groupcomm/commit/91fd85d4c7a0ff346ba833e52c1a22edf3187df3 > > <== > >> >> Section 6.1: “This approach consists in the KDC sending one individual rekeying >> message to each target group member.” The beginning of this sentence doesn’t >> seem right. Can you double check? > > ==>MT > > Now tried to reformulate, see https://github.com/ace-wg/ace-key-groupcomm/commit/04d4de9e1dd3f65efe89124939f670ede3fdd07a > > <== > >> >> Section 6.2.1: >> OLD: “The used encryption algorithm which SHOULD be the same >> one used to protect communications in the group.” NEW: “The used encryption >> algorithm SHOULD be the same one used to protect communications in the group.” > > ==>MT > > Fixed in: https://github.com/ace-wg/ace-key-groupcomm/commit/7bbe27aebdbfd76b8ded27141803fff44b0d27e1 > > <== > >> >> Section 6.3: Paragraph starting with “In the second case, the sender protects a >> message using the new group keying material, but the recipient receives that >> message before having received the new group keying material.” >> >> Another >> suggestion to deal with this case: The recipient can store a message that it >> can’t decrypt temporarily for a limited time so that if it receives new group >> keying material shortly after, it can then decrypt those stored messages. > > ==>MT > > We have kept the text as is. > > In principle, the suggested approach is possible, but we don't expect it to be practically enforceable. Typical secure communication protocols are such that a recipient rightly discards an incoming message, if this is not successfully decrypted and verified. > > <== > >> >> Section 10. >> DDOS attack possibilities - I can see some possibilities for DDOS >> where Clients can overwhelm KDC by sending unexpected or unknown fields. There >> might be more - can authors provide some possible DDOS attack vectors? > > ==>MT > > The second from last paragraph of Section 10.2 (the one starting with "The KDC needs to have a mechanism") already discusses a possible, concrete Denial of Service vector against the KDC, and how the KDC can counteract and mitigate its exploitation. > > More generally, the KDC is expected to be implemented by a host well-equipped in terms of resources and capable to handle a relatively high load. Therefore, we do not expect that Clients can realistically overwhelm the KDC by means of unexpected or unknown fields in their requests. > > Also, a first protection for the KDC is the requirement for a node to have first of all successfully uploaded a valid access token and established a secure communication association. > > With this considered, we do not believe that we need any additional text. > > <== > >> >> Thanks, >> Vidhi >> >> > > -- > Marco Tiloca > Ph.D., Senior Researcher > > Phone: +46 (0)70 60 46 501 > > RISE Research Institutes of Sweden AB > Box 1263 > 164 29 Kista (Sweden) > > Division: Digital Systems > Department: Computer Science > Unit: Cybersecurity > > https://www.ri.se <https://www.ri.se/><OpenPGP_0xEE2664B40E58DA43.asc>_______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art
- [Tsv-art] Tsvart last call review of draft-ietf-a… Vidhi Goel via Datatracker
- Re: [Tsv-art] Tsvart last call review of draft-ie… Marco Tiloca
- Re: [Tsv-art] Tsvart last call review of draft-ie… Vidhi Goel