[secdir] Secdir last call review of draft-ietf-clue-protocol-17
Aanchal Malhotra <email@example.com> Wed, 17 October 2018 18:27 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E959130DEF; Wed, 17 Oct 2018 11:27:07 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Aanchal Malhotra <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com
Date: Wed, 17 Oct 2018 11:27:07 -0700
Subject: [secdir] Secdir last call review of draft-ietf-clue-protocol-17
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2018 18:27:07 -0000
Reviewer: Aanchal Malhotra Review result: Not Ready Reviewer: Aanchal Malhotra. Review Result: Ready Two points: 1) The Security Considerations section of the draft-ietf-clue-protocol mostly references back to the I-D.ietf-clue-framework, I-D.ietf-clue-data-model-schema and I-D.ietf-clue-datachannel. So the fate of this document depends on the approval of all other CLUE related documents that it references. 2) Clarification: There is one new threat introduced in the security considerations section of this document whose proposed solution is not clear to me. Following is the text: "...In theory an implementation could choose not to announce all of the versions it supports if it wants to avoid such leakage, though at the expenses of interoperability. With respect to the above considerations, it is noted that the OPTIONS state is only reached after the CLUE data channel has been successfully set up. This ensures that only authenticated parties can exchange 'options' and related 'optionsResponse' messages and hence drastically reduces the attack surface which is exposed to malicious parties." Question: If a participant CP1 does not announce all of the versions it supports to CP2, does not that imply the same threat/attack from CP1 that you are trying to avoid from CP2? In other words, CP1 could force CP2 to use a non-up-to-date version of the protocol or the one that it knows how to break. Am I missing something here?
- [secdir] Secdir last call review of draft-ietf-... Aanchal Malhotra
- Re: [secdir] Secdir last call review of draft-i... Adam Roach