Last Call Review of draft-ietf-clue-protocol-17
review-ietf-clue-protocol-17-secdir-lc-malhotra-2018-10-17-01

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?