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

["DRAGE, Keith (Keith)" <[e-mail]>]

> 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 document is pretty much correct within the constraints we gave it, which is to 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 (for 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 time 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 want to do something. But that is what it is, new work.

Keith

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Iñaki Baz Castillo
> Sent: 16 September 2011 12:08
> To: Horvath, Ernst
> Cc: [e-mail]
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> 
> 2011/9/16 Horvath, Ernst <[e-mail]>:
> > Well, I read RFC 3261 differently. 8.1.2 says:
> >
> >   Otherwise, the procedures are applied to the first Route header field
> >   value in the request (if one exists), or to the request's Request-URI
> >   if there is no Route header field present.  These procedures yield an
> >   ordered set of address, port, and transports to attempt.  Independent
> >   of which URI is used as input to the procedures of [4], if the
> >   Request-URI specifies a SIPS resource, the UAC MUST follow the
> >   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.  SIPS in a Dialog
> >
> >   If the Request-URI in a request that initiates a dialog is a SIP URI,
> >   then the UAC needs to be careful about what to use in the Contact
> >   header field (in case Record-Route is not used for this hop).  If the
> >   Contact header field was a SIPS URI, it would mean that the UAS would
> >   only accept mid-dialog requests that are sent over secure transport
> >   on each hop.  Since the Request-URI in this case is a SIP URI, it is
> >   quite possible that the UA sending a request to that URI might not be
> >   able to send requests to SIPS URIs.  If the top Route header field
> >   does not contain a SIPS URI, the UAC MUST use a SIP URI in the
> >   Contact header field, even if the request is sent over a secure
> >   transport (e.g., the first hop could be re-using a TLS connection to
> >   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=tls (with SIP schema), ;transport=tls-sctp and so on.
> 
> --
> Iñaki Baz Castillo
> <[e-mail]>
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use [e-mail] for questions on how to develop a SIP
> implementation.
> Use [e-mail] for new developments on the application of sip.
> Use [e-mail] for issues related to maintenance of the core SIP
> specifications.