[TLS] Comments on draft-ietf-mmusic-rfc2326bis-13

Eric Rescorla <ekr@networkresonance.com> Fri, 07 July 2006 00:18 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fye3N-0004Jp-L3; Thu, 06 Jul 2006 20:18:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fye3M-0004JZ-Bl; Thu, 06 Jul 2006 20:18:40 -0400
Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fye3L-0007ye-0g; Thu, 06 Jul 2006 20:18:40 -0400
Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id E8147222426; Thu, 6 Jul 2006 17:26:46 -0700 (PDT)
To: mmusic@ietf.org
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19)
Date: Thu, 06 Jul 2006 17:18:38 -0700
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20060707002646.E8147222426@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: tls@ietf.org
Subject: [TLS] Comments on draft-ietf-mmusic-rfc2326bis-13
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

At the Dallas IETF, Magnus asked for a review by the TLS WG
of draft-ietf-mmusic-rfc2326bis. I've read the document,
focusing on S 18. Comments follow:

S 3.3:
I think more guidance is needed about session identifiers.
They need to be chosen not just randomly but cryptographically
randomly, right? A citation to RFC 4086 seems appropriate
here.

S 9.3, 9.4:
Is there some rationale available for 10 seconds, 5 seconds,
etc.?

11.3:

   server. This allows the client to enumerate in priority order the
   transport mechanisms and parameters acceptable to it, while the
   server can select the most appropriate. It is expected that the

I'm not sure what "priority order" means here. Descending order
of preference?

11.7-11.8:
I'm confused about the parameters format. I don't really understand
how it can be undefined. Can this be explained better?

14.10:
It should be noted that no-cache isn't a DRM-type measure,
since caches can cheat--there's no security measure stopping
it....



S 18: Security and Proxies

The basic theory behind RTSPS's interaction with non-transparent 
proxies is that the client gives the proxy instructions in
the RTSP Headers about what TLS policies to follow. It can use
any of three policies:

1. Any	     (Accept any peer certificate)
2. Proxy     (Do whatever you think is appropriate)
3. User	     (Accept the following certificates and prompt
	     me for any others)

I've got several concerns about this design.

1. There doesn't seem to be any way to communicate your 
   cipher suite preferences.
2. I don't see how certificate-based client authentication 
   works. Is it supposed to?
3. You need to provide the entire cert chain in
   Connection-Credentials, not just the certifcate.

Minor comments.

   section any reference to proxy will be to a non-transparent proxy,
   which requires to inspect/manipulate the RTSP messages.

s/requires/needs/

   the end server. Note that, when the client checks the server

Remove the comma after "that"

-Ekr



    




_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls