Re: Using TLS in the first hop - Bug in RFC 5630

Addressing the thread in general rather than Hadriel in particular.

Please remember that RFC 5630 did not set out to create a complete solution=
 to secure communication. That was left to separate work and noone at the t=
ime seemed interested in doing that next step, so it was abandoned.

What RFC 5630 set out to do was to define what occurred if you followed the=
 RFC 3261 mechanisms, and to correct some of RFC 3261 that was known to be =
wrong and to attempt to make sure that if SIPS was used in the Request-URI,=
 then TLS was used end to end. I do not believe there was ever an intent to=
 try and control what happened hop by hop. If you know that TLS is being us=
ed on the local hop, but have absolutely no knowledge of whether it is bein=
g used anywhere else, how useful is that?

While section 5, the normative section appears somewhat long, if you look a=
t the impact of RFC 5630 in the way it changed RFC 3261 as stated in append=
ix A, it actually did very little in terms of change to the original RFC 32=
61 material.

I'm not actually sure that the issue you point out in 3.1.3 actually impact=
s the above drastically.

Do note however that if you want to perform new work, you probably need to =
take it to the SIPCORE list.

Keith

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Hadriel Kaplan
> Sent: 15 September 2011 17:31
> To: I=F1aki Baz Castillo
> Cc: <[email protected]>; Olle E. Johansson
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> =

> =

> Oh I'm well aware of that. :)
> I assumed this whole discussion was theoretical.
> In *practice* using sips is tough.  Some systems don't support it and will
> choke on the scheme, while some systems seem to ignore the extra "s".  And
> there are real problems with it even if you do everything by the book.
> For example, it's not like Alice's UA will actually have a TLS cert to be
> able to be a TLS server/listen-socket, so you can't open a TLS connection
> to her UA regardless, ever.  And with TCP in general you have to treat her
> Registered Contact connection as an outbound-style flow (ie, like an
> alias'ed connection-reuse), even if the UAC doesn't indicate RFC 5626 nor
> 5923.  Once you do that, using "sip" instead of "sips" contact works, or
> has so far for us.  YMMV.
> =

> -hadriel
> =

> =

> On Sep 15, 2011, at 12:03 PM, I=F1aki Baz Castillo wrote:
> =

> > 2011/9/15 Hadriel Kaplan <[email protected]>:
> >> No I mean if Bob wants to Refer Carol to Alice, or Alice to Carol
> (since that Refer can be sent out of dialog to Alice's contact).
> >
> > Initial requests sent to a Contact address rather than being sent to
> > an AoR are always problematic. The same occurs in attended trasfer
> > when the REFER is sent within the dialog and contains a Refer-To with
> > the endpoint Contact URI. Such URI could be no reachable if it's
> > between some kind of NAT's (regardless the user used STUN).
> >
> > --
> > I=F1aki Baz Castillo
> > <[email protected]>
> =

> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use [email protected] for questions on how to develop a SIP
> implementation.
> Use [email protected] for new developments on the application of sip.
> Use [email protected] for issues related to maintenance of the core SIP
> specifications.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use [email protected] for questions on how to develop a SIP =
implementation.
Use [email protected] for new developments on the application of sip.
Use [email protected] for issues related to maintenance of the core SIP spec=
ifications.