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

From: Eric Rescorla <[email-masked]>
Date: Thu, 06 Jul 2006 17:18:38 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls