Subject: [MMUSIC] RTSP: Upgrade to TLS

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Dec 2006 15:59:26 +0100

Hi,

Some months ago Stephen Farrel made a review of the TLS related parts of 
the RTSP 2.0 spec. One of the comments he had was:

"1. I guess there's no point in arguing this, but I thought the 
START_TLS approach was favoured over stuff like "rtsps:". If there's a 
specific reason here for this then maybe it'd be worth stating (even if 
its only historic)."

I have looked at this and reviewed how this is done in HTTP.
ftp://ftp.rfc-editor.org/in-notes/rfc2817.txt

To me it seems that changing the TLS procedures in the RTSP 2.0 draft is 
the right choice. The draft currently defines a separate port. My 
question is if the WG agrees on this?

In that case are everyone fine with mandating that servers only need to 
support an upgrade function working as defined in RFC 2817? That would 
mean abandoning any deployed TLS clients that uses port 332 for all its 
TLS connections.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Dec 2006 12:15:51 -0800

Magnus Westerlund <[email-masked]> writes:

> Hi,
>
> Some months ago Stephen Farrel made a review of the TLS related parts
> of the RTSP 2.0 spec. One of the comments he had was:
>
> specific reason here for this then maybe it'd be worth stating (even
> if its only historic)."
>

Despite being PS, RFC2817 isn't really how things are mostly
done in HTTP. Rather, RFC 2818 (HTTPS) is how things are done.

> To me it seems that changing the TLS procedures in the RTSP 2.0 draft
> is the right choice. The draft currently defines a separate port. My
> In that case are everyone fine with mandating that servers only need
> to support an upgrade function working as defined in RFC 2817? That
> would mean abandoning any deployed TLS clients that uses port 332 for
> all its TLS connections.

There are two issues here:

1. Signalling to the client that it should expect TLS 
   (that's what https:// does)
2. Signalling to the server that the client would like TLS.
   This can be done either via a separate port or via an
   upgrade-type mechanism.

-Ekr

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Dec 2006 10:27:31 +0100

> done in HTTP. Rather, RFC 2818 (HTTPS) is how things are done.

Okay, but that doesn't prevent us in RTSP 2.0 to adopt this way as the 
primary way of doing TLS. RTSP over TLS hasn't really been defined and 
it seems reasonable to define the possibilities to do this over a single 
port and avoid the need to reopen a TCP connection if one wasn't aware 
of the need for TLS from the start.

>    (that's what https:// does)

Yes, and that is already defined for RTSP in the "rtsps" URI schema.

>    This can be done either via a separate port or via an

And that is what I am proposing to be done using a upgrade type 
mechanism instead of using a separate port. As I see we have three 
alternatives on how to accomplish this.

A. Require the usage of a separate port (332) when using TLS. It is 
already registered and I assume that this is how any old RTSP 1.0 
implementations does it.

B. Use a upgrade mechanism similar to RFC 2817.

C. Require servers to implement both A and B. Let the clients choose 
mechanism.

So opinions on what should be used please.

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Dec 2006 06:37:20 -0800

Magnus Westerlund <[email-masked]> writes:

> it seems reasonable to define the possibilities to do this over a
> single port and avoid the need to reopen a TCP connection if one
> wasn't aware of the need for TLS from the start.

Right. I was just providing context.

> C. Require servers to implement both A and B. Let the clients choose

If you've already defined a separate port, I don't see a lot of
virtue in moving to an upgrade mechanism. Note that there
are two types of mechanism here:

1. A demux. The client sends some message that says "TLS coming
   next" and the server better accept it. This is a simple 
   port-sharing scheme.
2. Opportunistic upgrade. The client and the server detect that
   they jointly support TLS and auto-upgrade to it. This is
   what (e.g., SMTP STARTTLS is basically intended to do).
   
If you already have a special URL and so you're not doing opportunistic
(which seems like the case) the only reason for demux scheme is
to save ports. And if you've already got a port allocated...

-Ekr

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 22 Dec 2006 10:48:55 -0600

> If you already have a special URL and so you're not doing 
> opportunistic (which seems like the case) the only reason for 
> demux scheme is to save ports. And if you've already got a 
> port allocated...

Is there a NAT traversal problem to worry about?
That's the other reason why you might want to use the same port.