Re: Issue LC90

Rogers, Tony wrote:
> Surely the whole point of reliable messaging is that there WON'T BE a 
> replay - reliable messaging will take all messages with the same 
> identifier (in whatever form that is) and will only present one copy of 
> the message to the layer above.
>  

This is true only if the QoS of the reliability layer is at-most-once or 
once-and-only-once; false if it is at-least-once (in which case, very 
likely multiple deliveries don't matter -- from the application 
semantics POV, but may matter from a DoS POV).

-Anish
--

> Bit hard to replay-attack such a system, wouldn't you agree? Your 
> replays will be absolutely pointless; well, they might help the 
> reliability :-)
>  
> Tony
> 
>     -----Original Message-----
>     *From:* public-ws-addressing-request@w3.org on behalf of David Hull
>     *Sent:* Tue 28-Jun-05 6:20
>     *To:* Abbie Barbir
>     *Cc:* Christopher B Ferris; Prasad Yendluri; Francisco Curbera;
>     public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
>     *Subject:* Re: Issue LC90
> 
>     +1 as well :-)
> 
>     I think we all agree now that, despite my mis-statement, the RM* ID
>     will also not change with a retransmission.
> 
>     This doesn't change anything with respect to LC90.  The point is
>     still that the [message id] doesn't change with a retransmission
>     (assuming it's there at all), and therefore SHOULD NOT be used in
>     detecting replays.
> 
>     Re-reading the current text for the nth time, I think what it's
>     trying to say is that the /message/ should include a timestamp or
>     other datum that /does/ change with a retransmission, but that's not
>     what it says.
> 
>     Again, I'm perfectly fine with taking the current text out entirely
>     and leaving such discussion to the security-related specifications. 
>     If it does stay, though, it needs to be clearer.  It should either
>     say more clearly that a /message /should include a timestamp or
>     whatever truly unique (and securely signed) datum, or (my
>     preference) just say clearly that [message id] is not that datum and
>     leave the rest to the security specs.
> 
>     Abbie Barbir wrote:
> 
>>
>>     +1
>>     abbie
>>
>>     > -----Original Message-----
>>     > From: public-ws-addressing-request@w3.org
>>     > [mailto:public-ws-addressing-request@w3.org] On Behalf Of
>>     > Christopher B Ferris
>>     > Sent: Monday, June 27, 2005 4:08 PM
>>     > To: Prasad Yendluri
>>     > Cc: David Hull; Francisco Curbera;
>>     > public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
>>     > Subject: Re: Issue LC90
>>     >
>>     >
>>     >
>>     > +1
>>     >
>>     > The retransmission will have the same
>>     > Sequence/Identifier+MessageNumber as
>>     > the original. It doesn't change.
>>     > I believe the same could be said of ws-reliability.
>>     >
>>     > Cheers,
>>     >
>>     > Christopher Ferris
>>     > STSM, Emerging e-business Industry Architecture
>>     > email: chrisfer@us.ibm.com
>>     > blog: http://webpages.charter.net/chrisfer/blog.html
>>     > phone: +1 508 377 9295
>>     >
>>     > public-ws-addressing-request@w3.org wrote on 06/27/2005 03:50:20
>>     PM:
>>     >
>>     > >
>>     > >
>>     > > David Hull wrote:
>>     > > 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.
>>     > > Actually my understanding is quite the opposite. The
>>     > sequence Id and
>>     > > the
>>     > messageNumber in sequence
>>     > > must remain the same for retransmissions. Where as no such
>>     > requirement
>>     > on timestamp. I don't
>>     > > believe retransmissions will have a separate sequence number. The
>>     > messageId stays the same. Given
>>     > > that I think it is useful to state this..
>>     > > 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
>>     > >
>>     >
>>     >
>>     >
>>
>

Received on Tuesday, 28 June 2005 01:33:44 UTC