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

Christer Holmberg <> Wed, 28 April 2010 06:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D18B93A6AC5 for <>; Tue, 27 Apr 2010 23:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.511
X-Spam-Status: No, score=-4.511 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OlasRVe2qB7y for <>; Tue, 27 Apr 2010 23:04:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9503C3A6A26 for <>; Tue, 27 Apr 2010 23:04:52 -0700 (PDT)
X-AuditID: c1b4fb3d-b7bf6ae000005bec-b5-4bd7cff65f14
Received: from (Unknown_Domain []) by (Symantec Brightmail Gateway) with SMTP id 2E.39.23532.6FFC7DB4; Wed, 28 Apr 2010 08:04:38 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 28 Apr 2010 08:04:38 +0200
Received: from ([]) by ([]) with mapi; Wed, 28 Apr 2010 08:04:37 +0200
From: Christer Holmberg <>
To: Sandra Murphy <>
Date: Wed, 28 Apr 2010 08:04:36 +0200
Thread-Topic: [secdir] secdir review of draft-ietf-sipcore-info-events
Thread-Index: AcrmTKDb4U+hsjmvQzOs2yqAtTsObwAS7naA
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>, "" <>, "" <>, Adam Roach <>
Subject: Re: [secdir] secdir review of draft-ietf-sipcore-info-events
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Apr 2010 06:04:57 -0000

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.