Re: [Sipping] Exploders drafts

[Gonzalo Camarillo <[e-mail]>]

Cullen,

Thanks for the comments. Inline:

Cullen Jennings wrote:

> Few comments on these.
> 
> On draft-camarillo-sipping-exploders-03.txt section 1 - para 2.
> 
> This nicely points out the requirements for exploders - I like it. It does
> seem like a reasonable compression scheme would solve this requirement
> equally well. Other explained to me this does not work due to inadequacies
> in sigcomp but might be worth pointing this out.
> 
> You might make an argument that a solution that took all the final exploded
> messages and sent them over an appropriately compressed link uses no more
> bandwidth on behalf of the sender than this and resulted in the same
> bandwidth usage on the receivers part and therefore the scheme proposed here
> was no worse a DOS attack problem than say compressed access links are.

Good point.

> I imagine recommending logging as a solution for SPAM with exploders is
> going to, ah, raise some concerns about the desirability of this scheme.

In my opinion, having the exploder assert the identity of the sender 
would be enough, but some folks had some concerns regarding privacy. 
That is, the sender does not want the exploder to disclose his 
identity... we may mention that logging should be used in this case to 
avoid anonymous spammers, but that in other cases is not needed...

> In the section on saying users must agree to receive stuff from an exploder,
> it would be nice to say that users must be able to easy revoke this. Having
> an explicit SIP mechanism for a user to grant permission to receive
> explosions, and more importantly, remove that permission grant, would make
> this better. It's interesting, in many ways the exploders is similar to
> publish but publish did not seem to have the same range of concerns about
> amplification, DOS, and message relay. Might want to figure out how to make
> it have the security properties more like publish.

I am not sure if we need a *SIP* mechanism for this. Using an 
out-of-band mechanism such as a web page would work fine.

> 
> On draft-garcia-sipping-message-exploder-00.txt
> 
> The embedded headers in the URI are nice but raise lots of issues. For
> example, if I insert a P-Asserted-Identity header with a fake name, will it
> be used? Or perhaps a Route header that caused the message to go to someone
> that had not agreed to receive exploded messages.
> 

These issues are already described in RFC 3261 talking about clients 
finding a SIP URI somewhere (e.g., in a web page) and using it. RFC 3261 
advices not to populate potentially dangerous headers... the same should 
apply here.

> The " The MESSAGE exploder MUST NOT copy any security body (such as an
>       S/MIME signed body) addressed to the MESSAGE exploder to the
>       outgoing MESSAGE request.  This includes, e.g., security bodies
>       signed with the public key of the exploder."
> This confuses me. If it was signed, it would be signed with the public key
> of the UA sending the request to the exploder? I'm just not sure what you
> are getting at with this. Is this the exploder must not relay any S/MIME
> body? 

Yes, it is confusing. The intention of that paragraph was to point out 
that the exploder should not populate information intended for it (the 
exploder). We'll rephrase it.


> In the security section - last paragraph. Not sure what you are proposing
> here. If I wanted to send an encrypted message to A and B, what would I do.
> I assume encrypt the List A,B with the public key of the exploder then
> provide a copy of the message that was encrypted with a content encryption
> key (call it the CEK) then encrypt the CEK with the public key of A and
> separately with B then bundle this all up somehow and send it. 

Yes, that would be the idea. I agree that we need to clarify that. In 
any case, I have not added mot text to the security considerations 
sections of all these drafts because I want to have face-to-face 
discussions before I document the details of the solutions. Once we 
agree on the way we want to go, I will take care of documenting these 
types of details.

  You mention
> integrity protection with S/MIME too - are you assuming that the exploder
> knows the public key of the UA sending the request?

When it comes to integrity protect the contents of the list between the 
client and the exploder, yes, the exploder would need to know it.

> 
> If the exploder has authenticated the sender, perhaps it should put the
> identity of the sender in the From of the messages it sends. This raises
> issues with trying to be Anonymous and user an exploder but perhaps this is
> a feature not a bug.

I agree that privacy should be mentioned in the draft.

Thanks for your comments,

Gonzalo



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP