Last Call Review of draft-ietf-clue-protocol-17
|Requested rev.||no specific revision|
|Type||Last Call Review|
|Team||Security Area Directorate (secdir)|
Genart Last Call review of -17 by Francis Dupont
Opsdir Last Call review of -17 by Zitao Wang
|Draft last updated||2018-10-17|
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?