Subject: RE: [Sip] A sips: trial balloon for you to shoot down

From: "Attila Sipos" <[email-masked]>
Date: Wed, 1 Nov 2006 21:09:24 -0000

>> In short, we're saying "If you  
>> want to honor the operational requirements of a sips: URI scheme,  
>> then you MUST NOT downgrade the protection of the signaling to less  
>> than TLS on any hop. If you do, then you have not met the  
>> requirements of sips:, and you are lying about your security".

But you are defining the requirements of sips by simply
saying that any PBX on the SIP gateway is not secure.
Some people would say that the PBX is secure.

Maybe a good way around this is for SIP entities to
indicate if they came from or went to PSTN.
Then people could decide if this was good enough security
for the requirements of their call.
I still fell sips should be allowed but that sips somehow
let the use decide if the security is good enough
(just like a user can decide if HTTPS is good enough
when the certificate check fails).

	Attila

>> -----Original Message-----
>> From: Dean Willis [mailto:[email-masked]]
>> Sent: 01 November 2006 20:37
>> To: Attila Sipos
>> Cc: IETF SIP List
>> Subject: Re: [Sip] A sips: trial balloon for you to shoot down
>> 
>> 
>> 
>> On Nov 1, 2006, at 5:00 AM, Attila Sipos wrote:
>> 
>> >
>> >>> Furthermore, gateways to other protocols not
>> >>> offering equally strong protections MUST NOT exercise 
>> the sips: URI
>> >>> scheme. In particular, PSTN gateways MUST NOT use sips:, 
>> since the
>> >>> PSTN itself does not offer equivalent protections and there is no
>> >>> ability to determine whether the PSTN segment might be
>> >>> converted back to a sip: request somewhere downstream.
>> >
>> > I don't think you will get agreement on this.
>> >
>> > I think this rule will have to be very different.  Instead
>> > of saying that we MUST or MUST NOT, it should be a section
>> > on making readers aware of the security implications.
>> > In my opinion, it's a policy thing, not a standards thing.
>> >
>> 
>> The 2119-language here is in the requirements of practices, not the  
>> requirements for a protocol design. In short, we're saying "If you  
>> want to honor the operational requirements of a sips: URI scheme,  
>> then you MUST NOT downgrade the protection of the signaling to less  
>> than TLS on any hop. If you do, then you have not met the  
>> requirements of sips:, and you are lying about your security". In  
>> short, you are violating the contract of transitive trust.
>> 
>> > There is a benefit in having secure SIP being used upto
>> > the PSTN gateway.
>> >
>> 
>> Sure. And with the description of sip: URI processing given earlier  
>> (it will be secured if it can be secured) then sip: gives 
>> you as good  
>> of security as you would get by lying about your compliance with  
>> sips:. So placing a call using a sip: URI to the PSTN gateway would  
>> produce secure SIP.
>> 
>> --
>> Dean
>> 
>> 
>> 
>> 

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

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Nov 2006 15:28:19 -0600

> when the certificate check fails).

I don't disagree, but like John Elwell, you appear to be asking for a  
new reporting mechanism that is beyond the scope of informational or  
BCP documents to define.

If we extended RC 3261 to have the sort of thing you're talking  
about, then we could change the BCP to take this new mechanism into  
account.

A similar approach can be seen in my existing BCP wording, which  
basically says "Since outbound gives us a way to overcome the  
limitation that made the last-hop exception necessary, we now  
consider it bad practice to use the last-hop exception. Use outbound  
instead".

--
Dean