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

Iñaki Baz Castillo <> Fri, 16 September 2011 12:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D57221F8B4D for <>; Fri, 16 Sep 2011 05:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.648
X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5i2pfwKiIXmZ for <>; Fri, 16 Sep 2011 05:44:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DA68F21F869E for <>; Fri, 16 Sep 2011 05:44:01 -0700 (PDT)
Received: by qyk33 with SMTP id 33so3866418qyk.10 for <>; Fri, 16 Sep 2011 05:46:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id r38mr1840589qci.254.1316177176199; Fri, 16 Sep 2011 05:46:16 -0700 (PDT)
Received: by with HTTP; Fri, 16 Sep 2011 05:46:16 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Fri, 16 Sep 2011 14:46:16 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
To: "DRAGE, Keith (Keith)" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, "Horvath, Ernst" <>
Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Session Initiation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Sep 2011 12:44:02 -0000

2011/9/16 DRAGE, Keith (Keith) <>om>:
> 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.

Thanks, I understand what you mean.

IMHO the main problem is "mixing" the transport for a specific node in
the path with the requirement of a secure transport for the whole
path. Given this thread is clear that there are errors in the design
making it unusable.

Another "error" (IMHO) is the aim of RFC 3261 in considering TLS (over
TCP) not a transport, but a secure layer over TCP. But that is ironic
since that just applies to URI ;transport param, but in Via transport
field we do have "TLS" and "TCP" as separate values.

Things would be much easier as follows (just an initial idea):

- Consider TLS-over-TCP as a real transport (the same for TLS over
SCTP) so we have ;transport=tls / tls-sctp.

- Completely remove SIPS schema (the real pain here).

- Create any new mechanism for requiring a whole secure path. For
example, by adding a ;sec param to the Request URI and Contact URI. In
this way, the UAS MUST also add ;sec to the Contact header in the
response, so all the in-dialog requests would have ;sec in the Request
URI.  Proxies should add ;sec to Record-Route headers in this case.
If an UAC or proxy has to route a request whose top Route (or RURI if
no Route is present) has ;sec param, then it MUST use a secure
transport. If such URI contains a ;transport param with values "udp",
"tcp" or "sctp" then that's an error and the request should be
And that's all.

Of course this idea must be improved (a lot) :)


Iñaki Baz Castillo