Re: [secdir] secdir review of draft-ietf-sipcore-info-events

[Christer Holmberg <[e-mail]>]

Hi Sandy, 

>>>>>This specification sort-of provides a SIP-based tunnel for 
>>>>>application protocols.
>>>>>
>>>>> 1: What prevents (or allows detection of) insertion of bogus Info 
>>>>> Package specifications? (e.g. by a proxy). If nothing, then why is 
>>>>> this ok?
>>>>>
>>>>
>>>> This is the general way that SIP works, and it applies to all the 
>>>> SIP header fields. It's not great, but proxies are implicitly 
>>>> trusted to do the right thing. If it's a problem for INFO, then it's 
>>>> a problem for everything that has ever used or will ever use SIP.
>>>
>>> Aye, and therein lies the rub.  ;-}
>>>
>>> In my usual broken-record nagging, insider failures are hard to 
>>> protect against, sometimes impossible.  But knowing just how bad 
>>> things might get (how much damage an insider failure could 
>>> potentially cause) might be a good idea. It might inspire people to 
>>> put strong operational controls in place.
>>> Buy a bigger liability policy. Abandon all hope ye who enter here. 
>>> etc.
>>>
>>> When I made some similar comments on a different SIP draft a while 
>>> back, there was a discussion on the sip wg list of writing down 
>>> somewhere what the wg chair called the "please molest me" security 
>>> model. I didn't follow the discussion to the end, so I don't know if 
>>> that ever got past the good intention stage and if so where the 
>>> written down text ended up.
>>
>> I guess Adam can comment on the status about that.
>>
>> However, I see that as a generic work, and not something that should be done in the Info-Events draft.
> 
>I wasn't intending to comment strictly on the info draft.  I 
>was agreeing with Adam's comment that this problem was common 
>to all of SIP.  If the sip wg did work or is doing work on 
>cautionary tales about proxies in general, then that work 
>could and should be noted in the info draft. 
>That's the scope of impact on the info draft.

AFAIK the sipcore wg is currently not doing such work.

Regards,

Christer