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

> So IMHO SIPS and TLS is broken and it can only work when the full path
> is secure (which is unfeasible in most of the environments). This
> needs a rework ...

This conclusion is nothing new - it was essentially the conclusion of those=
 working on RFC 5630. But it is not RFC 5630 that needs the rework; that do=
cument is pretty much correct within the constraints we gave it, which is t=
o define what happens with the existing protocol and make minimum fixes to =
the existing protocol (indeed the original charter item was only the first =
half of this). =


There was a recognition that more could be achieved with a new mechanism (f=
or example there was a draft from Vijay Gurbani), but that would have been =
a separate charter item, and noone seemed to have the enthusiasm at the tim=
e to work on it. That doesn't mean that that situation still persists and I=
'm sure you understand the process for bringing new work into IETF if you w=
ant to do something. But that is what it is, new work.

Keith

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> I=F1aki Baz Castillo
> Sent: 16 September 2011 12:08
> To: Horvath, Ernst
> Cc: [email protected]
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> =

> 2011/9/16 Horvath, Ernst <[email protected]>:
> > Well, I read RFC 3261 differently. 8.1.2 says:
> >
> > =A0 Otherwise, the procedures are applied to the first Route header fie=
ld
> > =A0 value in the request (if one exists), or to the request's Request-U=
RI
> > =A0 if there is no Route header field present. =A0These procedures yiel=
d an
> > =A0 ordered set of address, port, and transports to attempt. =A0Indepen=
dent
> > =A0 of which URI is used as input to the procedures of [4], if the
> > =A0 Request-URI specifies a SIPS resource, the UAC MUST follow the
> > =A0 procedures of [4] as if the input URI were a SIPS URI.
> >
> > This behaviour overrides the transport indicated in the Route header if
> > the Request-URI is SIPS. And it applies to mid-dialog requests as well.
> > BTW, RFC 5630 has some text on your original point:
> >
> > 5.1.1.2. =A0SIPS in a Dialog
> >
> > =A0 If the Request-URI in a request that initiates a dialog is a SIP UR=
I,
> > =A0 then the UAC needs to be careful about what to use in the Contact
> > =A0 header field (in case Record-Route is not used for this hop). =A0If=
 the
> > =A0 Contact header field was a SIPS URI, it would mean that the UAS wou=
ld
> > =A0 only accept mid-dialog requests that are sent over secure transport
> > =A0 on each hop. =A0Since the Request-URI in this case is a SIP URI, it=
 is
> > =A0 quite possible that the UA sending a request to that URI might not =
be
> > =A0 able to send requests to SIPS URIs. =A0If the top Route header field
> > =A0 does not contain a SIPS URI, the UAC MUST use a SIP URI in the
> > =A0 Contact header field, even if the request is sent over a secure
> > =A0 transport (e.g., the first hop could be re-using a TLS connection to
> > =A0 the proxy as would be the case with [RFC5626]).
> =

> Hi, this definitely tells me that SIPS and TLS is impossible, but just
> in the case of full TLS in the whole path.
> =

> I insist on the bug I've reported for RFC 5630: If the client sets a
> SIP Contact URI and sends the request using TLS, then it would receive
> incoming in-dialog requests via UDP or TCP, but not TLS. This does not
> make sense as the caller could use just SIP over TLS, and in case of
> NAT this would never work as the proxy/server could never send a TCP
> or UDP request to the client.
> =

> So IMHO SIPS and TLS is broken and it can only work when the full path
> is secure (which is unfeasible in most of the environments). This
> needs a rework, or maybe Olle is right and we should use
> ;transport=3Dtls (with SIP schema), ;transport=3Dtls-sctp and so on.
> =

> --
> 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.