Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips

[Michael Thomas <[e-mail]>]

You're undoubtably right -- I've been wondering about this -- so let me 
say that
my problem is with anything that supposedly dictates security beyond 
what the
next hop is but cannot be verified by the would be dictator.

Barring end to end security of some form, anything that purports to 
elevate the
authenticity and/or confidentiality of the signaling is bound to be 
misinterpretred,
and that's what sips real sin is. If this is really a BCP -- which I'm 
becoming
convinced is the only way to reasonably sell -- not oversell -- this 
desire, then
we should work in that direction. Signaling for security that one has no 
means
of verifying is just plain dumb.

       Mike

Rohan Mahy wrote:

> Michael,
>
> You seem to have a mistaken impression that transport=tls means
> something it does not/is actually useful.  Unfortunately,
> transport=tls only affects the next hop, it interferes with NAPTR
> selection of the actual underlying transport (TCP, UDP, SCTP, DCCP),
> it looks really ugly in URIs, and it is a pain in the arse to enter on
> a phone keypad.
>
> I don't really believe the last two are a big deal, but the important
> thing here is that sips: has the semantics that most folks think
> transport=tls should have, but transport=tls actually does not have.
>
> thanks,
> -rohan
>
>
> On 5/30/06, Michael Thomas <[e-mail]> wrote:
>
>> Vijay K. Gurbani wrote:
>>
>> > Michael Thomas wrote:
>> >
>> >> My question is whether it's answer to _any_ problem. My last 
>> attempt at
>> >> getting and answer was fruitless. What attacks do SIPS thwart in real
>> >> life
>> >> that honest operators and transport=tls doesn't? Real life good guy,
>> >> bad guy situations would be helpful.
>> >
>> >
>> > Sorry -- catching up after a forced, and not entirely un-welcome,
>> > lull introduced by the weekend.
>> >
>> > Dean has pointed out one answer to this; namely, "reduces the
>> > probability of an accidental downgrade by intermediate proxies
>> > between the UAC and the proxy responsible for the AOR, if those
>> > proxies bother to honor it."
>>
>>
>> How does it do that? Why does this sort of behavior require an ill
>> conceived protocol element when it is really a BCP in disguise?
>>
>> >
>> > A couple more: sips provides confidentiality of traffic
>> > and authentication of a proxy and registrar to a UAC.  Admittedly,
>> > one could do this with transport=tls, but this particular
>> > construct is deprecated in rfc3261.  Currently, there is no means
>> > for a UAC to authenticate a registrar or a proxy; sips at the
>> > very least, allows for the signaling between the UAC and a
>> > registrar to be on an confidential and authenticated channel.
>>
>>
>> So SIPS is overloaded with transport=tls; Bletch.
>

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