Re: Using TLS in the first hop - Bug in RFC 5630
"DRAGE, Keith (Keith)" <[email protected]> Sat, 8 Oct 2011 11:08:56 +0200
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <EDC0A1AE77C57744B664A310A0B23AE220D4C5BD@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> |
--===============2371219433215530105== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE220D4C5BDFRMRSSXCHMBSC3d_" --_000_EDC0A1AE77C57744B664A310A0B23AE220D4C5BDFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All drafts help things along, but please do have the discussion on DISPATCH= or SIPCORE. It doesn't belong here. Keith ________________________________ From: Samir Srivastava [mailto:[email protected]] Sent: 07 October 2011 20:34 To: DRAGE, Keith (Keith) Cc: Hadriel Kaplan; I=F1aki Baz Castillo; <[email protected]>; Olle E. Johansson Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630 In line prefixed with SS>> Regards Samir On Thu, Sep 15, 2011 at 10:05 AM, DRAGE, Keith (Keith) <keith.drage@alcatel= -lucent.com<mailto:[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 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. SS>> Refer the draft http://datatracker.ietf.org/doc/draft-srivastava-dis= patch-avoidance-of-threats/ submitted recently. And let me know your comme= nts. What we intend to do in future? As per my recollection Security Adviso= r was not in agreement with my 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 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]> [mailto:sip-bounc= [email protected]<mailto:[email protected]>] On Behalf Of > Hadriel Kaplan > Sent: 15 September 2011 17:31 > To: I=F1aki Baz Castillo > Cc: <[email protected]<mailto:[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 wil= l > choke on the scheme, while some systems seem to ignore the extra "s". An= d > 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 he= r > 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]<mailto:HKaplan@acmepac= ket.com>>: > >> 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]<mailto:[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]<mailto:[email protected].= edu> for questions on how to develop a SIP > implementation. > Use [email protected]<mailto:[email protected]> for new developments on t= he application of sip. > Use [email protected]<mailto:[email protected]> for issues related to maint= enance 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]<mailto:[email protected]= u> for questions on how to develop a SIP implementation. Use [email protected]<mailto:[email protected]> for new developments on the= application of sip. Use [email protected]<mailto:[email protected]> for issues related to mainten= ance of the core SIP specifications. --_000_EDC0A1AE77C57744B664A310A0B23AE220D4C5BDFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"= > <META content=3D"MSHTML 6.00.2900.6129" name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D367210809-08102011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>All drafts help things along, but please do have t= he=20 discussion on DISPATCH or SIPCORE.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D367210809-08102011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D367210809-08102011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>It doesn't belong here.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D367210809-08102011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D367210809-08102011><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Keith</FONT></SPAN></DIV><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Samir Srivastava=20 [mailto:[email protected]] <BR><B>Sent:</B> 07 October 2011=20 20:34<BR><B>To:</B> DRAGE, Keith (Keith)<BR><B>Cc:</B> Hadriel Kaplan; I= =F1aki=20 Baz Castillo; <[email protected]>; Olle E. Johansson<BR><B>Subject:</B> = Re:=20 [Sip] Using TLS in the first hop - Bug in RFC 5630<BR></FONT><BR></DIV> <DIV></DIV> <DIV>In line prefixed with SS>></DIV> <DIV> </DIV> <DIV>Regards</DIV> <DIV>Samir<BR><BR></DIV> <DIV class=3Dgmail_quote>On Thu, Sep 15, 2011 at 10:05 AM, DRAGE, Keith (= Keith)=20 <SPAN dir=3Dltr><<A=20 href=3D"mailto:[email protected]">keith.drage@alcatel-lucent= .com</A>></SPAN>=20 wrote:<BR> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: rgb(2= 04,204,204) 1px solid">Addressing=20 the thread in general rather than Hadriel in particular.<BR><BR>Please= =20 remember that RFC 5630 did not set out to create a complete solution to= =20 secure communication. That was left to separate work and noone at the t= ime=20 seemed interested in doing that next step, so it was=20 abandoned.<BR></BLOCKQUOTE> <DIV> </DIV> <DIV>SS>> Refer the draft <A=20 href=3D"http://datatracker.ietf.org/doc/draft-srivastava-dispatch-avoidan= ce-of-threats/">http://datatracker.ietf.org/doc/draft-srivastava-dispatch-a= voidance-of-threats/</A> =20 submitted recently. And let me know your comments. What we intend to do i= n=20 future? As per my recollection Security Advisor was not in agreement with= my=20 proposal. But it was told that there will be a day when this solution wil= l be=20 needed,</DIV> <DIV> </DIV> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: rgb(2= 04,204,204) 1px solid"><BR>What=20 RFC 5630 set out to do was to define what occurred if you followed the = RFC=20 3261 mechanisms, and to correct some of RFC 3261 that was known to be w= rong=20 and to attempt to make sure that if SIPS was used in the Request-URI, t= hen=20 TLS was used end to end. I do not believe there was ever an intent to t= ry=20 and control what happened hop by hop. If you know that TLS is being use= d on=20 the local hop, but have absolutely no knowledge of whether it is being = used=20 anywhere else, how useful is that?<BR><BR>While section 5, the normativ= e=20 section appears somewhat long, if you look at the impact of RFC 5630 in= the=20 way it changed RFC 3261 as stated in appendix A, it actually did very l= ittle=20 in terms of change to the original RFC 3261 material.<BR><BR>I'm not=20 actually sure that the issue you point out in 3.1.3 actually impacts th= e=20 above drastically.<BR><BR>Do note however that if you want to perform n= ew=20 work, you probably need to take it to the SIPCORE list.<BR> </BLOC= KQUOTE> <BLOCKQUOTE class=3Dgmail_quote=20 style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: rgb(2= 04,204,204) 1px solid"><BR>Keith<BR> <DIV class=3Dim><BR>> -----Original Message-----<BR>> From: <A=20 href=3D"mailto:[email protected]">[email protected]</A> [mailto:<= A=20 href=3D"mailto:[email protected]">[email protected]</A>] On Behal= f=20 Of<BR></DIV>> Hadriel Kaplan<BR>> Sent: 15 September 2011=20 17:31<BR>> To: I=F1aki Baz Castillo<BR>> Cc: <<A=20 href=3D"mailto:[email protected]">[email protected]</A>>; Olle E. Johansson<BR= > <DIV class=3Dim>> Subject: Re: [Sip] Using TLS in the first hop - Bu= g in=20 RFC 5630<BR>><BR>><BR></DIV> <DIV> <DIV></DIV> <DIV class=3Dh5>> Oh I'm well aware of that. :)<BR>> I assumed th= is=20 whole discussion was theoretical.<BR>> In *practice* using sips is t= ough.=20 Some systems don't support it and will<BR>> choke on the schem= e,=20 while some systems seem to ignore the extra "s". And<BR>> ther= e are=20 real problems with it even if you do everything by the book.<BR>> Fo= r=20 example, it's not like Alice's UA will actually have a TLS cert to=20 be<BR>> able to be a TLS server/listen-socket, so you can't open a T= LS=20 connection<BR>> to her UA regardless, ever. And with TCP in ge= neral=20 you have to treat her<BR>> Registered Contact connection as an=20 outbound-style flow (ie, like an<BR>> alias'ed connection-reuse), ev= en if=20 the UAC doesn't indicate RFC 5626 nor<BR>> 5923. Once you do t= hat,=20 using "sip" instead of "sips" contact works, or<BR>> has so far for = us.=20 YMMV.<BR>><BR>> -hadriel<BR>><BR>><BR>> On Sep 15,= =20 2011, at 12:03 PM, I=F1aki Baz Castillo wrote:<BR>><BR>> > 201= 1/9/15=20 Hadriel Kaplan <<A=20 href=3D"mailto:[email protected]">[email protected]</A>>:<= BR>>=20 >> No I mean if Bob wants to Refer Carol to Alice, or Alice to=20 Carol<BR>> (since that Refer can be sent out of dialog to Alice's=20 contact).<BR>> ><BR>> > Initial requests sent to a Contact= =20 address rather than being sent to<BR>> > an AoR are always=20 problematic. The same occurs in attended trasfer<BR>> > when the = REFER=20 is sent within the dialog and contains a Refer-To with<BR>> > the= =20 endpoint Contact URI. Such URI could be no reachable if it's<BR>> &g= t;=20 between some kind of NAT's (regardless the user used STUN).<BR>>=20 ><BR>> > --<BR>> > I=F1aki Baz Castillo<BR>> > <= ;<A=20 href=3D"mailto:[email protected]">[email protected]</A>><BR>><BR>>=20 _______________________________________________<BR>> Sip mailing lis= t=20 <A href=3D"https://www.ietf.org/mailman/listinfo/sip"=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/sip</A><BR>> T= his=20 list is essentially closed and only used for finishing old business.<BR= >>=20 Use <A=20 href=3D"mailto:[email protected]">[email protected]= lumbia.edu</A>=20 for questions on how to develop a SIP<BR>> implementation.<BR>> U= se <A=20 href=3D"mailto:[email protected]">[email protected]</A> for new develop= ments=20 on the application of sip.<BR>> Use <A=20 href=3D"mailto:[email protected]">[email protected]</A> for issues relate= d to=20 maintenance of the core SIP<BR>>=20 specifications.<BR>_______________________________________________<BR>S= ip=20 mailing list <A href=3D"https://www.ietf.org/mailman/listinfo/sip= "=20 target=3D_blank>https://www.ietf.org/mailman/listinfo/sip</A><BR>This l= ist is=20 essentially closed and only used for finishing old business.<BR>Use <A= =20 href=3D"mailto:[email protected]">[email protected]= lumbia.edu</A>=20 for questions on how to develop a SIP implementation.<BR>Use <A=20 href=3D"mailto:[email protected]">[email protected]</A> for new develop= ments=20 on the application of sip.<BR>Use <A=20 href=3D"mailto:[email protected]">[email protected]</A> for issues relate= d to=20 maintenance of the core SIP=20 specifications.<BR></DIV></DIV></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY= ></HTML> --_000_EDC0A1AE77C57744B664A310A0B23AE220D4C5BDFRMRSSXCHMBSC3d_-- --===============2371219433215530105== 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. --===============2371219433215530105==--