[TLS] TLS 1.2 draft comments

Inline comments, for 7 fragments of the I-D:-

1.     - The connection is private. Symmetric cryptography is used for
       data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for
       this symmetric encryption are generated uniquely for each
       connection and are based on a secret negotiated by another
       protocol (such as the TLS Handshake Protocol). The Record
       Protocol can also be used without encryption.

There are errors both technical and semantic in the above. Fortezza connections

don’t have unique keys per connection. We also need to stop including within

'key' objects such as "mac secrets." Furthermore, the secret

may always not be "negotiated" by TLS. Furthermore, if the Record Protocol

can be used without encryption, we can hardly have the privacy asserted

in the topic sentence: without encryption, its hard to get the data

origin authentication of the TLS application messages that allows for

expressing the very expectation of pairwise privacy!

2.    - The connection is reliable. Message transport includes a message
       integrity check using a keyed MAC. Secure hash functions (e.g.,
       SHA, MD5, etc.) are used for MAC computations. The Record
       Protocol can operate without a MAC, but is generally only used in
       this mode while another protocol is using the Record Protocol as
       a transport for negotiating security parameters.

Keep the point about RP can operate without a MAC, strike

the general qualifier. Either one can or cannot...operate without

MacTags. We readers don’t need protocol design advice from TLS WG

stuffed into an interoperability spec, thanks!

3. One such encapsulated protocol, the TLS Handshake
Protocol, allows the server and client to authenticate each other and
to negotiate an encryption algorithm and cryptographic keys

While we are at it, lets get this accurate."One such encapsulated protocol, the TLS Handshake
Protocol, allows the server and client to authenticate each other and
to negotiate a __ciphersuite, key, and varios secrets.__" If I argue with myself,

the word negotiate should really become "agree". In combination

with the first use of the ciphersuite and keys, the final KDF executes

an "agreement" between the named parties roles, as to those objects. One

is forced to (I) use, (2) rely, and (3) agree, in the final protocol.

4. The peer's identity can be authenticated using asymmetric, or
       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
       authentication can be made optional, but is generally required
       for at least one of the peers.

how about: The peer's identity can be authenticated using asymmetric, or
       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
       authentication can be made optional, but is generally required
       for at least one of the peers __in order to establish appropriate assurance for

the key exchange component of a ciphersuite.__"

5. The negotiation of a shared secret is secure: the negotiated
       secret is unavailable to eavesdroppers, and for any authenticated
       connection the secret cannot be obtained, even by an attacker who
       can place himself in the middle of the connection.

How about: The negotiation of a shared secret is secure: the negotiated
       secret is unavailable except to the server and client, each party can confirm

       the other possesses the secret, and for any authenticated
       connection the secret cannot be _obtained from the wire_ , even by an attacker who
       can place himself in the middle of the connection.

6. 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
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS.

To address EAP-TLS session resumption rules and TLSPSK rules on self-signed certs etc:

   the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of _or below_ TLS.

7. Concerning section 1.1:

"     - Allow the client to indicate which hash functions it supports.

     - Allow the server to indicate which hash functions it supports

     - Addition of support for authenticated encryption with additional
     data modes."

distinguish indicating hash functions, from mac functions. hash functions used in securing

the handshake are not the same as mac functions used in the record-layer. Without

reading further, I don’t know which are being referred to in this summary.

I don’t know what "authenticated encryption" is, only that support for it has

been added. Apparently, it has "data modes". Its presumably not a confidentiality

service. Its presumably not the privacy service. Its X. From the form of the

summary, it may be an X.800 mechanism, not a service.

Peter.