Subject: Re: [MMUSIC] RTSP: Upgrade to TLS

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Apr 2007 18:06:13 +0200

Eric Rescorla skrev:
> Magnus Westerlund <[email-masked]> writes:
> 
>> Eric Rescorla skrev:
>>> 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:
>>>>
>>>> "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
>>> Despite being PS, RFC2817 isn't really how things are mostly
>>> 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.
> 
> Right. I was just providing context.
> 
> 
>>> 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.
>> 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.
> 
> 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...
> 

So the simple solution (from work perspective) to this problem is to use 
the different ports and not define anything new.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
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: Mon, 16 Apr 2007 20:25:54 -0700

At Mon, 16 Apr 2007 18:06:13 +0200,
> the different ports and not define anything new.

Pretty much, yeah...

-Ekr