LC Comment: (editorial) Security implications of [message id] in re-transmissions

Section 4 of the Core states:

    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.

This essentially echoes advice found in at least one reliability 
standard under development.  In fact, the issue of distinguishing 
legitimate retransmissions from illegitimate replays is generic to 
layering reliability on top of security, whether or not message ids are 
present, as any message at all may be retransmitted.   The only reason 
that [message id] might need to be called out specially is that, given 
its name and putative function, one might be tempted to use it as a 
message identifier for reliability purposes.  Note that this advice is 
only relevant to implementors of reliable messaging, who are presumably 
aware of the issues in any case.  Nothing anyone else can do regarding 
[message id] will affect the situation one way or the other.

The advice that the message identifier be combined with other data is 
not quite correct.  The relevant restriction is simply that the [message 
id] should not be used as a uniqueness criterion for security purposes.  
That is, it should be left out of uniqueness determination entirely, 
despite its name possibly suggesting otherwise.  The text would be 
better worded along the lines of:

    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.