[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on Mandatory Ciphers and a Proposal
On Mon, 28 Jul 1997, David P. Kemp wrote:
> Alternatively, could you post the complete text of what you think the
> TLS RFC should include in the way of compliance requirements, so we
> have something concrete to discuss? Maybe it will win quick agreement,
> maybe not.
The old "put up or shut up" demand is always fair game. Given the
objections to a mandatory cipher suite, here are context diffs for a
compromise proposal that I would find acceptable. I can't say if the IESG
would find this acceptable -- it doesn't meet the IESG statement which
remanded the document, but it does address the underlying issues.
The meat of this proposal is at the end (section 10).
*** draft-ietf-tls-protocol-03.txt Thu May 22 17:40:56 1997
--- tls-framework.txt Tue Jul 29 15:50:34 1997
***************
*** 116,121 ****
--- 116,122 ----
8.1.1. RSA 44
8.1.2. Diffie-Hellman 44
9. Application data protocol 44
+ 10. Profiling Requirements for TLS 44
A. Protocol constant values 44
A.1. Reserved port assignments 44
A.2. Record layer 45
***************
*** 157,163 ****
1. Introduction
! | The primary goal of the TLS Protocol is to provide privacy and data
| integrity between two communicating applications. The protocol is
composed of two layers: the TLS Record Protocol and the TLS
Handshake Protocol. At the lowest level, layered on top of some
--- 158,165 ----
1. Introduction
! | The primary goal of the TLS Protocol is to permit the negotiation
! of a security layer which potentially provides privacy and data
| integrity between two communicating applications. The protocol is
composed of two layers: the TLS Record Protocol and the TLS
Handshake Protocol. At the lowest level, layered on top of some
***************
*** 206,213 ****
negotiation communication without being detected by the parties
to the communication.
! One advantage of TLS is that it is application protocol independent.
! ] Higher level protocols can layer on top of the TLS Protocol
] transparently. The TLS standard, however, does not specify how
] protocols add security with TLS; the decisions on how to initiate
] TLS handshaking and how to interpret the authentication certificates
--- 208,214 ----
negotiation communication without being detected by the parties
to the communication.
! ] Higher level protocols can layer on top of the TLS Protocol relatively
] transparently. The TLS standard, however, does not specify how
] protocols add security with TLS; the decisions on how to initiate
] TLS handshaking and how to interpret the authentication certificates
***************
*** 218,225 ****
The goals of TLS Protocol, in order of their priority, are:
! 1. Cryptographic security: TLS should be used to establish a secure
! connection between two parties.
Dierks, T. Expires September, 1997 [Page 4]
--- 219,227 ----
The goals of TLS Protocol, in order of their priority, are:
! 1. Security layer framework: TLS is used to negotiate a security
! layer acceptable to the client and server. TLS without an
! agreeable cipher suite provides no security whatsoever.
Dierks, T. Expires September, 1997 [Page 4]
***************
*** 234,242 ****
application domain) will be able to successfully connect. For
instance, if the server supports a particular hardware token,
and the client does not have access to such a token, then the
! ] connection will not succeed. There is no required set of ciphers
! ] for minimal compliance, so some implementations may be unable to
! ] communicate.
3. Extensibility: TLS seeks to provide a framework into which new
public key and bulk encryption methods can be incorporated as
--- 236,242 ----
application domain) will be able to successfully connect. For
instance, if the server supports a particular hardware token,
and the client does not have access to such a token, then the
! ] connection will not succeed.
3. Extensibility: TLS seeks to provide a framework into which new
public key and bulk encryption methods can be incorporated as
***************
*** 2447,2491 ****
state. The messages are treated as transparent data to the record
layer.
! A. Protocol constant values
! This section describes protocol types and constants.
! A.1. Reserved port assignments
! At the present time TLS is implemented using TCP/IP as the base
! ] networking technology, although the protocol should be useful over
! ] any transport which can provide a reliable stream connection. The
! IANA reserved the following Internet Protocol [IP] port numbers for
! use in conjunction with the SSL 3.0 Protocol, which we presume will
! be used by TLS as well.
! Dierks, T. Expires September, 1997 [Page 44]
! INTERNET-DRAFT TLS 1.0 March 1997
! | While we describe these existing port assignments for completeness,
! | in general, protocol designers and implementors should be the ones
! | to decide on how security can be incorporated into their protocol
! | using TLS, including the mechanisms for negotiating to start TLS and
! | the requirements and meaning of that connection (such as
! | interpretation of exchanged certificates).
! 443 Reserved for use by Hypertext Transfer Protocol with SSL (https)
! 465 Reserved for use by Simple Mail Transfer Protocol with SSL
! (ssmtp).
! 563 Reserved for use by Network News Transfer Protocol with SSL
! (snntp).
- 636 Reserved for Light Directory Access Protocol with SSL (ssl-ldap)
-
- 990 Reserved (pending) for File Transfer Protocol with SSL (ftps)
-
- 995 Reserved for Post Office Protocol with SSL (spop3)
-
A.2. Record layer
struct {
--- 2447,2493 ----
state. The messages are treated as transparent data to the record
layer.
! 10. Profiling Requirements for TLS
! TLS, by itself, provides nothing more than a security negotiation
! and framing mechanism. A TLS profile specifies how TLS is used
! with a particular application protocol. TLS MUST NOT be used with
! IETF standards track protocols without a standards track or IESG
! approved experimental profile.
! A TLS profile MUST specify the following:
! (1) One or more cipher suites which together provide minimally
! acceptable security for that protocol and MUST be implemented by
! compliant implementations. The cipher suite
! TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is suggested as a primary
! candidate.
+ (2) Whether TLS is started by using a standards track extension
+ command or a separate port.
+ (2A) In the case of an extension command, the profile MUST fulfill
+ the requirements for a protocol extension to the application
+ protocol, state at what octet the TLS negotiation begins for client
+ and server, how active attacks which disable the extension command
+ are dealt with, and what effect the "finished" message has on the
+ application protocol.
! (2B) In the case of a separate port, the profile MUST include the
! IANA registered port number, document the impact on URLs and state
! how active attacks which disable the port are dealt with.
! (3) How TLS-level authentication interacts with application
! protocol level authentication and how TLS authentication impacts
! the use of proxy connections.
! (4) What impact integrity protection or encryption at a particular
! level has on application protocol data access, if any.
! A. Protocol constant values
! This section describes protocol types and constants.
A.2. Record layer
struct {