ISSUE: Message-id management

[Mark Taylor]

On Thu, 1 May 2008, Mike Fitzpatrick wrote:

>> The most obvious way to do it is for the hub to set its hub-msg-id along
>> the following lines:
>>
>>   <hub-msg-id> = <sender-id>-<sender-msg-id>
>>
>> then, as you describe, when the response comes back to the hub bearing the
>> <hub-msg-id>, the hub can unpack this to work out where and how it's
>> supposed to forward that response on to the original sender.
>
>    If this is the intent of having a separate hub-msg-id then  it should be
> spelled out
> more clearly in the text,

My footnote on page 16 is intended to outline this.  But I don't
think it is the place of the standard to say that hubs should use
any particular id format or algorithm to achieve the required
results - that's down to the implementation.

>> The benefit of allowing the sender-msg-id and hub-msg-id to be different
>> (though they don't have to be if the hub wants to arrange things
>> otherwise) is so that the sender and the hub can both decide how they
>> want to format their part of the ID.  As well as not wanting to dictate
>> implementation details where it's not necessary, there may
>> be practical benefits to this - for instance a particular hub
>> implementation might want to add a checksum for added security.
>> If it is obliged by the standard to use a msg-id of a particular form,
>> and generated by the sender, that would be outlawed.
>
>    You should have stopped at the 'not wanting to dicate' argument.  Unless

well you can stop reading there if you like.

> the receiving app knows it is getting a checksum in the id and does
> something
> with it a checksum value is no more secure than adding "-foo" since all
> we need is the reply to give us back the same msg-id.  If you want checksum
> security it should be in the original sender, but then we're back to
> dictating
> implementation details.

No, I was thinking of a checksum generated by the hub and re-examined
by the hub when the reply comes back so that it can tell that it is 
a hub-msg-id that it generated earlier rather than a faked one. 
Under your scheme, a client could 
maliciously call reply() with a made-up msg-id of 
<sender-id>-<made-up-id> and the hub would forward that response to 
the named sender, who never actually sent a message in the first place.
If the hub is allowed to insert some redundancy into the msg-id it
can have a chance of checking whether the ID it receives is one which
corresponds to a real message.  I'm not saying that we should spend
a lot of time worrying about that kind of security issue, but it's
the kind of implementation-dependent choice which hubs and clients
can make if they feel like it under my scheme (where hub and client
can choose any form they want for the IDs as long as the behaviour
is as prescribed) but blocked under your scheme (where the form of
the msg-id is prescribed).

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/