<speaking for mysef....>

<home_pw@msn.com> writes:

> 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.

In general, I don't agree that your proposed changes improve the
situation. This text (or minor variants) dates back to TLS 1.0 (and I
suspect back to SSLv3). Does anyone else in the WG support these
changes.


> 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.

I don't see the virtue of this change either. TLS-PSK doesn't run
below TLS and this WG is not in the business of standardizing 
anything EAP.


> 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'll put this on the list of things to change.


> 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.

"authenticated encryption wiht additional data". It's combined
confidentiality and message integrity in a single algorithm, as is
explained later in the document.

-Ekr


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