[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
- [TLS] Comments on draft-ietf-mmusic-rfc2326bis-13 Eric Rescorla