Subject: [Sipping] Exploders drafts

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 14 May 2004 15:46:41 +0300

Folks,

I have just submitted the following draft. Until it appears in the 
archives, you can fetch it from:

http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-exploders-03.txt

It describes the exploders' requirements and a framework to meet them. 
The framework includes references to the following documents, which will 
be discussed in the interim as well:

http://www.ietf.org/internet-drafts/draft-camarillo-sipping-uri-list-02.txt
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-adhoc-conferencing-00.txt
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-adhoc-simple-00.txt
http://www.ietf.org/internet-drafts/draft-garcia-sipping-message-exploder-00.txt

Best regards,

Gonzalo

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 17 May 2004 23:00:25 -0700

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.

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 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.

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.

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? 

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.  You mention
integrity protection with S/MIME too - are you assuming that the exploder
knows the public key of the UA sending the request?

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 don't feel strongly about these drafts one way or another so I hope these
comments get somewhat discounted as casual passer by - I know others have
thought about it much more. Perhaps the amplification issue in this B2BUA
based solution can be justified as no worse than the alternative solution to
the problem using compression with a proxy.

Cullen 

> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-adhoc-conferencing
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-adhoc-simple-00.tx>
t

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 18 May 2004 18:43:47 +0300

Cullen,

Thanks for the comments. Inline:

> was no worse a DOS attack problem than say compressed access links are.

Good point.

> 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...

> 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.

> 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.

> are getting at with this. Is this the exploder must not relay any S/MIME

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.

> 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
> 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.

> issues with trying to be Anonymous and user an exploder but perhaps this is

I agree that privacy should be mentioned in the draft.

Thanks for your comments,

Gonzalo

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 19 May 2004 13:07:26 +0300

> that had not agreed to receive exploded messages.

First, this issue is applicable not only to the MESSAGE exploder draft, 
but to any other exploder document. It can happen with INVITE, SUBSCRIBE 
  or REFER as well.

Second, the exploder implements a SIP UA functionality, meaning that if 
implements RFC 3325, it is able to distinguish when the 
P-Asserted-Identity is trusted or not, as required by the RFC. Based on 
this trustness of the asserted identity, the exploder may implement 
local policy to pass the header to the other side or not.

> are getting at with this. Is this the exploder must not relay any S/MIME

This is obviously wrong. The text shold speak about an "encrypted body" 
and "bodies encrypted with the public key of the explodr".

The idea is very simple: if the exploder is able to decrypt an encrypted 
body, it should not copy that encrypted body to the outgoing request, 
since the receiver will not be able to decrypted.

> separately with B then bundle this all up somehow and send it.  

Yes, that is how it should be done. I conquer that the text is not clear 
enough, we will clarify it.

> knows the public key of the UA sending the request?

That is the assumption.
> issues with trying to be Anonymous and user an exploder but perhaps this is

I don't think that the decision point is whether the user is 
authenticated or not. I belive the decision point is the user 
requirements expressed in the Privacy header. That will determine 
whether to populate the From header with the user ID or something else

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 May 2004 12:37:14 -0700

> since the receiver will not be able to decrypted.

I get it now - thanks.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 May 2004 12:41:10 -0700

> local policy to pass the header to the other side or not.

Ok, Seems like some text is needed.