Re: Issue LC90

If a message is retransmitted for reliability purposes, the payload
(that is, the message the reliability layer thinks it's sending) will be
retransmitted verbatim.  The [message id] is part of this, so it will be
the same in both versions, just as the other WSA headers will be, and
the body for that matter.  There will be /no part/ of the message
payload that could be used to tell if the message is a replay or a
retransmission.  This is why the reliability layer uses its own sequence
number.  The retransmission /will/ have a separate sequence number.  The
security layer can use this information to distinguish retransmissions
from replays.  It can't use anything in the payload.

The current text says that the security layer should take care to
consider information that will not change when trying to see if anything
has changed.  The new text points out that the [message id] will not
change with a retransmission and looking at it won't help.  Further, it
uses a SHOULD NOT, instead of a MUST NOT, so that anyone who really
wants to fold in redundant information is free to do so.

Francisco Curbera wrote:

>Issue LC90 proposes changing the following paragraph in the security
>section,
>
>"Some processors may use message identifiers ([message id]) as part of a
>uniqueness metric in order to detect replays of messages. Care should be
>taken to ensure that for purposes of replay detection, the message
>identifier is combined with other data, such as a timestamp, so that a
>legitimate retransmission of the message is not confused with a replay
>attack."
>
>to the alternate text,
>
>"For purposes of reliability and security, the [message id] property SHOULD
>regarded simply as another part of the message payload.  It SHOULD NOT be
>used as part of a uniqueness metric in order to detect replays of messages,
>as a message with a given [message id] may be legitimately re-sent for
>purposes of reliable transmission."
>
>We think that there is no justification to say that you one cannot use
>messageID as part of an uniqueness criterion for security purposes, so the
>"SHOULD NOT" in the proposed text is unjustified. The original text is more
>balanced, recognizing that message_if may be used and giving the right
>advice if one chooses to do so.
>
>I propose we close with no change.
>
>Paco
>
>
>
>  
>