Re: [Sipping] WGLC Review: draft-ietf-sipping-capacity-attribute-01.txt

[Gonzalo Camarillo <[e-mail]>]

Hi,

recommending S/MIME and SIPS has been the standard practice in all the 
drafts SIPPING has been producing in a long time. I do not think this 
draft is the place to discuss the relationship between TLS, IPsec, VPNs, 
etc. I believe such relationship must be tackled by the SIP 
specification and its updates.

Cheers,

Gonzalo


Samir Srivastava wrote:
> Hi Miguel,
> 
> My concerns were driven by the dynamic nature of cipher technologies.
> And we have the problems coming from others as SIPS is mentioned as
> *statically* for the security at numerous places.
> 
> IMHO, we should have boiler-plate kind of stuff in the security section
> which takes into the account the security provided by underlying secure
> protocol layers generically.
> 
> And then each specification addresses other security aspects for in
> particular to that specification in the separate paragraph in the
> Security Considerations.
> 
> Hopefully, it addresses the concerns of SIPS proponents in future.
> 
> Thx
> Samir
> 
>> -----Original Message-----
>> From: Miguel Garcia [mailto:[e-mail]]
>> Sent: Thursday, September 21, 2006 3:30 AM
>> To: Srivastava, Samir (SC100:8826)
>> Cc: Barnes, Mary (RICH2:B601); [e-mail];
>> [e-mail]
>> Subject: Re: [Sipping] WGLC Review:
> draft-ietf-sipping-capacity-attribute-
>> 01.txt
>>
>> I think the spirit of the text is not to exclude any technology. In
>> essence, any technology that is able to cypher SIP messages is
> suitable
>> to protect privacy. We should probably  mention TLS as an example of
> one
>> of such technologies.
>>
>> /Miguel
>>
>> Samir Srivastava wrote:
>>> Hi,
>>>
>>> What is the reason for not considering IPSEC tunnels in the text?
> DTLS
>>> is still open issue. So better open-ended text can be phrased like
>>>
>>> "... was sent over a secured channel provided by the underlying
> layers
>>> e.g.
>>> TLS, IPSEC ...."
>>>
>>> How long we want to carry S/MIME with it's deploy ability issues. If
>>> still we want to use S/MIME atleast known issues with it should be
>>> listed similar to 3261. Or reference to section of 3261 should be
> given.
>>>
>>> IMHO, SIP message means REQUEST and RESPONSE both. So the text
> should be
>>> well aligned like ".... SIP request unless the SIP request ..." or
> with
>>> the "message" word.
>>>
>>> Thx
>>> Samir
>>>
>>>> - Section 8, 3rd paragraph, 3rd sentence. "was" -> "is"
>>>> OLD:
>>>>    Eavesdroppers are able to watch URI-lists contained in SIP
>>>>    requests unless the SIP message was sent over a secured channel
>>> with
>>>>    Transport Layer Security (TLS) [3] or unless the URI-list body
>>> itself
>>>>    is encrypted with S/MIME [8].
>>>> NEW:
>>>>    Eavesdroppers are able to watch URI-lists contained in SIP
>>>>    requests unless the SIP message is sent over a secured channel
> with
>>>>    Transport Layer Security (TLS) [3] or unless the URI-list body
>>> itself
>>>>    is encrypted with S/MIME [8].
>>>>
>> --
>> Miguel A. Garcia           tel:[phone]
>> sip:[e-mail]
>> Nokia Research Center      Helsinki, Finland


_______________________________________________
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