Re: Using TLS in the first hop - Bug in RFC 5630
Samir Srivastava <[email protected]> Fri, 7 Oct 2011 12:33:34 -0700
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <CAK+SpiyoDWiqmyab-D0KpT0zsDL=xhN-pnxearFBXBWAz=v+dQ@mail.gmail.com> |
--===============1548222644105062994== Content-Type: multipart/alternative; boundary=20cf305640e7548bd604aeba84d7 --20cf305640e7548bd604aeba84d7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In line prefixed with SS>> Regards Samir On Thu, Sep 15, 2011 at 10:05 AM, DRAGE, Keith (Keith) < [email protected]> wrote: > Addressing the thread in general rather than Hadriel in particular. > > Please remember that RFC 5630 did not set out to create a complete soluti= on > to secure communication. That was left to separate work and noone at the > time seemed interested in doing that next step, so it was abandoned. > SS>> Refer the draft http://datatracker.ietf.org/doc/draft-srivastava-dispatch-avoidance-of-thre= ats/ submitted recently. And let me know your comments. What we intend to do in future? As per my recollection Security Advisor was not in agreement with m= y proposal. But it was told that there will be a day when this solution will be needed, > > What RFC 5630 set out to do was to define what occurred if you followed t= he > 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-UR= I, > then TLS was used end to end. I do not believe there was ever an intent t= o > try and control what happened hop by hop. If you know that TLS is being u= sed > on the local hop, but have absolutely no knowledge of whether it is being > used anywhere else, how useful is that? > > While section 5, the normative section appears somewhat long, if you look > at the impact of RFC 5630 in the way it changed RFC 3261 as stated in > appendix A, it actually did very little in terms of change to the origina= l > RFC 3261 material. > > I'm not actually sure that the issue you point out in 3.1.3 actually > impacts the above drastically. > > Do note however that if you want to perform new work, you probably need t= o > 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 connecti= on > > 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 n= or > > 5923. Once you do that, using "sip" instead of "sips" contact works, o= r > > 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 busines= s. > > 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 SI= P > 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. > --20cf305640e7548bd604aeba84d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>In line prefixed with SS>></div><div>=A0</div><div>Regards</div>= <div>Samir<br><br></div><div class=3D"gmail_quote">On Thu, Sep 15, 2011 at = 10:05 AM, DRAGE, Keith (Keith) <span dir=3D"ltr"><<a href=3D"mailto:keit= [email protected]">[email protected]</a>></span> w= rote:<br> <blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l= eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s= olid;" class=3D"gmail_quote">Addressing the thread in general rather than H= adriel in particular.<br> <br> 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.<br> </blockquote><div>=A0</div><div>SS>> Refer the draft=A0=A0=A0<a href= =3D"http://datatracker.ietf.org/doc/draft-srivastava-dispatch-avoidance-of-= threats/">http://datatracker.ietf.org/doc/draft-srivastava-dispatch-avoidan= ce-of-threats/</a>=A0 submitted recently. And let me know your comments. Wh= at we intend to do in future? As per my recollection Security Advisor was n= ot in agreement with my proposal. But it was told that there will be a day = when this solution will be needed,</div> <div>=A0</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left:= 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border= -left-style: solid;" class=3D"gmail_quote"> <br> 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?<br> <br> 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.<br> <br> I'm not actually sure that the issue you point out in 3.1.3 actually im= pacts the above drastically.<br> <br> Do note however that if you want to perform new work, you probably need to = take it to the SIPCORE list.<br>=A0</blockquote><blockquote style=3D"margin= : 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20= 4); border-left-width: 1px; border-left-style: solid;" class=3D"gmail_quote= "> <br> Keith<br> <div class=3D"im"><br> > -----Original Message-----<br> > From: <a href=3D"mailto:[email protected]">[email protected]</a>= [mailto:<a href=3D"mailto:[email protected]">[email protected]</a>] = On Behalf Of<br> </div>> Hadriel Kaplan<br> > Sent: 15 September 2011 17:31<br> > To: I=F1aki Baz Castillo<br> > Cc: <<a href=3D"mailto:[email protected]">[email protected]</a>>; Olle E. = Johansson<br> <div class=3D"im">> Subject: Re: [Sip] Using TLS in the first hop - Bug = in RFC 5630<br> ><br> ><br> </div><div><div></div><div class=3D"h5">> Oh I'm well aware of that.= :)<br> > I assumed this whole discussion was theoretical.<br> > In *practice* using sips is tough. =A0Some systems don't support i= t and will<br> > choke on the scheme, while some systems seem to ignore the extra "= ;s". =A0And<br> > there are real problems with it even if you do everything by the book.= <br> > For example, it's not like Alice's UA will actually have a TLS= cert to be<br> > able to be a TLS server/listen-socket, so you can't open a TLS con= nection<br> > to her UA regardless, ever. =A0And with TCP in general you have to tre= at her<br> > Registered Contact connection as an outbound-style flow (ie, like an<b= r> > alias'ed connection-reuse), even if the UAC doesn't indicate R= FC 5626 nor<br> > 5923. =A0Once you do that, using "sip" instead of "sips= " contact works, or<br> > has so far for us. =A0YMMV.<br> ><br> > -hadriel<br> ><br> ><br> > On Sep 15, 2011, at 12:03 PM, I=F1aki Baz Castillo wrote:<br> ><br> > > 2011/9/15 Hadriel Kaplan <<a href=3D"mailto:HKaplan@acmepacket= .com">[email protected]</a>>:<br> > >> No I mean if Bob wants to Refer Carol to Alice, or Alice to C= arol<br> > (since that Refer can be sent out of dialog to Alice's contact).<b= r> > ><br> > > Initial requests sent to a Contact address rather than being sent= to<br> > > an AoR are always problematic. The same occurs in attended trasfe= r<br> > > when the REFER is sent within the dialog and contains a Refer-To = with<br> > > the endpoint Contact URI. Such URI could be no reachable if it= 9;s<br> > > between some kind of NAT's (regardless the user used STUN).<b= r> > ><br> > > --<br> > > I=F1aki Baz Castillo<br> > > <<a href=3D"mailto:[email protected]">[email protected]</a>><br> ><br> > _______________________________________________<br> > Sip mailing list =A0<a href=3D"https://www.ietf.org/mailman/listinfo/s= ip" target=3D"_blank">https://www.ietf.org/mailman/listinfo/sip</a><br> > This list is essentially closed and only used for finishing old busine= ss.<br> > Use <a href=3D"mailto:[email protected]">sip-implemento= [email protected]</a> for questions on how to develop a SIP<br> > implementation.<br> > Use <a href=3D"mailto:[email protected]">[email protected]</a> for new= developments on the application of sip.<br> > Use <a href=3D"mailto:[email protected]">[email protected]</a> for issue= s related to maintenance of the core SIP<br> > specifications.<br> _______________________________________________<br> Sip mailing list =A0<a href=3D"https://www.ietf.org/mailman/listinfo/sip" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/sip</a><br> This list is essentially closed and only used for finishing old business.<b= r> Use <a href=3D"mailto:[email protected]">sip-implementors@cs= .columbia.edu</a> for questions on how to develop a SIP implementation.<br> Use <a href=3D"mailto:[email protected]">[email protected]</a> for new deve= lopments on the application of sip.<br> Use <a href=3D"mailto:[email protected]">[email protected]</a> for issues rel= ated to maintenance of the core SIP specifications.<br> </div></div></blockquote></div><br> --20cf305640e7548bd604aeba84d7-- --===============1548222644105062994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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. --===============1548222644105062994==--